> > It would not provide anything, and it might encourage a false sense of > concurrency-safety.
I understand. Thanks! On Fri, Mar 19, 2021 at 12:40 AM Gedare Bloom <ged...@rtems.org> wrote: > On Thu, Mar 18, 2021 at 11:25 AM Richi Dubey <richidu...@gmail.com> wrote: > > > > Thanks for your help! I read the doc. > >> > >> This is definitely an area where you have to think a bit at the > >> conceptual purpose of the API/feature to realize why it can't > >> work or is unsafe in SMP mode. > > > > I understand. The only reason we would want to have a feature like no > preemption for a thread is to give it the exclusive right to some data for > some time. Since there are multiple threads running on multiple processors, > no preemption for one thread does not help us achieve anything. Got it. > > > > But, what if we still want such a feature? Why is it impossible to have? > I don't see any harm in having a processor run a no preempt thread in an > SMP environment. > > > It would not provide anything, and it might encourage a false sense of > concurrency-safety. > > > Thanks! > > > > On Wed, Mar 17, 2021 at 6:14 PM Joel Sherrill <j...@rtems.org> wrote: > >> > >> > >> > >> On Wed, Mar 17, 2021 at 1:54 AM Richi Dubey <richidu...@gmail.com> > wrote: > >>> > >>> Hi, > >>> > >>> I am debugging tm19 running on Strong APA scheduler. It gives the > following error: > >>> rtems_signal_catch FAILED -- expected (RTEMS_SUCCESSFUL) got > (RTEMS_NOT_IMPLEMENTED) > >>> > >>> which is due to line 167. This arises because the variable > is_non_preempt_mode_supported in _Scheduler_Control of SMP Strong APA > scheduler is set to false. > >>> > >>> On further checking, I can see that almost all the SMP schedulers have > this variable set as false in cpukit/include/rtems/scheduler.h. Please let > me know why this is the case. What would I need to do to support non > preempt tasks in the Strong APA scheduler? > >> > >> > >> No preempt does not make sense in an SMP environment. The idea with > >> no preempt is that by setting it, the thread runs without another > thread (only > >> interrupts) preempting it. This works fine on uniprocessor systems but > since > >> there are always multiple threads running in SMP, the assumption is > >> violated. > >> > >> No preempt is an old RTOS feature and sometimes has a name like > >> scheduler lock. It is just one of the features/APIs not safe for SMP > that > >> we removed or made inoperable in SMP mode. This section in the > >> manual covers these features: > >> > >> > https://docs.rtems.org/branches/master/c-user/symmetric_multiprocessing_services.html#application-issues > >> > >> This is definitely an area where you have to think a bit at the > >> conceptual purpose of the API/feature to realize why it can't > >> work or is unsafe in SMP mode. > >> > >> --joel > >>> > >>> _______________________________________________ > >>> devel mailing list > >>> devel@rtems.org > >>> http://lists.rtems.org/mailman/listinfo/devel > > > > _______________________________________________ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
