> > 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.hu...@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. >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
