About is_non_preempt_mode_supported

[Richi Dubey]

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.

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
>> <https://git.rtems.org/rtems/tree/testsuites/tmtests/tm19/task1.c#n167>.
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210318/b09c2d86/attachment-0001.html>