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

[Richi Dubey]

>
> 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



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

> On 21/08/2020 11:34, Richi Dubey wrote:
>
> > _SMP_Preempt calls _Thread_Dispatch_update_heir which
> > calls _Thread_Dispatch_request which sends an interrupt
> > with _CPU_SMP_Send_interrupt.
> Yes.
> > This interrupt would have set the executing equal to heir but would've
> > taken unpredictable time,
> Yes, this is how it works. The scheduler asks for a thread dispatch, but
> when it takes place is out of the control of the scheduler.
> > but explicitly calling _Thread_Dispatch_enable(other_cpu) right after
> > _SMP_Preempt(...node_on_other_cpu...) sets the executing corresponding
> > to the other_cpu's cpu control right away, is that correct?
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200821/d4c4faa4/attachment.html>