About is_non_preempt_mode_supported

[Jan.Sommer at dlr.de]

> -----Original Message-----
> From: devel <devel-bounces at rtems.org> On Behalf Of Gedare Bloom
> Sent: Thursday, March 18, 2021 8:11 PM
> To: Richi Dubey <richidubey at gmail.com>
> Cc: rtems-devel at rtems.org <devel at rtems.org>
> Subject: Re: About is_non_preempt_mode_supported
> 
> On Thu, Mar 18, 2021 at 11:25 AM Richi Dubey <richidubey at 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.
> 

How would I temporarily disable preemption for the current thread on its specific core only?
For example, a thread sends several events to a set of other threads and this sending should not be interrupted in case the first event wakes up a sleeping thread of higher priority on the same CPU.
If there are no other resource dependencies, would a simple rtems_interrupt_local_disable be the right thing to do?

Best regards,

    Jan

> > Thanks!
> >
> > On Wed, Mar 17, 2021 at 6:14 PM Joel Sherrill <joel at rtems.org> wrote:
> >>
> >>
> >>
> >> On Wed, Mar 17, 2021 at 1:54 AM Richi Dubey <richidubey at 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_multiprocessi
> >> ng_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 at rtems.org
> >>> http://lists.rtems.org/mailman/listinfo/devel
> >
> > _______________________________________________
> > devel mailing list
> > devel at rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel