When does heir become executing on calling _Thread_Dispatch_request from another cpu?

[Richi Dubey]

I understand what you're saying. Accessing the chain of scheduled node to
figure out which node is scheduled on which processor is a more formal and
safer way to do it than directly accessing a cpu's variable.

I'll refactor my code. Thank you.

On Fri, Aug 21, 2020 at 4:12 PM Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

> On 21/08/2020 11:54, Richi Dubey wrote:
>
> >     No, this would be completely wrong. You should never call
> >     _Thread_Dispatch_enable(other_cpu) and you should never modify the
> >     thread dispatch level inside the scheduler code. The only thing
> >     you can
> >     do is to update the heir and send requests via an inter-processor
> >     interrupt.
> >
> > Okay. So, to deal with the unpredictable time is it okay if I use heir
> > instead of executing in the following place (my aim is to get the
> > latest executing thread / to be executed thread on a cpu):
> >
> >
> >
> https://github.com/richidubey/rtems/blob/03d08d02b3e61570f2022845caa44ec6a261f677/cpukit/score/src/schedulerstrongapa.c#L243
> >
> https://github.com/richidubey/rtems/blob/03d08d02b3e61570f2022845caa44ec6a261f677/cpukit/score/src/schedulerstrongapa.c#L467
> >
> https://github.com/richidubey/rtems/blob/03d08d02b3e61570f2022845caa44ec6a261f677/cpukit/score/src/schedulerstrongapa.c#L248
> >
> In an SMP system you have to be very careful in which context you access
> which data. We definitely lack some formalized way to document this. You
> must not use the per-processor variables in your scheduler code. This
> would be completely wrong. For the scheduler it doesn't matter if the
> threads actually execute or not. The scheduler should use the chain of
> scheduled nodes to maintain the node to processor allocation.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200821/567493b8/attachment.html>