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
