About is_non_preempt_mode_supported
Richi Dubey
richidubey at gmail.com
Fri Mar 19 04:16:58 UTC 2021
>
> 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 <gedare at rtems.org> wrote:
> 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.
>
> > 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_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 at rtems.org
> >>> http://lists.rtems.org/mailman/listinfo/devel
> >
> > _______________________________________________
> > devel mailing list
> > devel at rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210319/fc4c78f1/attachment.html>
More information about the devel
mailing list