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