I understand, Thank you for the clarification. Last question:
_SMP_Preempt calls _Thread_Dispatch_update_heir which calls _Thread_Dispatch_request which sends an interrupt with _CPU_SMP_Send_interrupt. This interrupt would have set the executing equal to heir but would've taken unpredictable time, 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? On Fri, Aug 21, 2020 at 2:52 PM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 21/08/2020 11:12, Richi Dubey wrote: > > > Is it okay I directly call _Thread_Dispatch_enable while calling > > SMP_Preempt (since the latter does not call it) on another processor? > > This question is wrt the code at this line > > < > https://github.com/richidubey/rtems/blob/03d08d02b3e61570f2022845caa44ec6a261f677/cpukit/score/src/schedulerstrongapa.c#L245>. > > > > The thread dispatching works with locks unrelated to the scheduler. It > is all right do do thread dispatching in parallel to the execution of > scheduler code. The scheduler data structures are protected by the > scheduler lock. > > > > This question has comes up because set_affinity does the following in > > the order: > > _Scheduler_SMP_Preempt_and_schedule_highest_ready > > set_affinity > > enqueue. > > > > The strong APA's highest_ready preempt a different cpu and allocates a > > thread. This CPU can again be preempted while calling the enqueue > > corresponding to Strong APA, at which point it would require the > > latest scheduled thread on it (the one just assigned it to by > > highest_ready if it's the case). > The scheduler code should only use the scheduler internal data > structures. It should define which thread should execute on which > processor. That a thread actually executes on the processor happens > asynchronously to the scheduler operations and is not the business of > the scheduler. This is the job of the thread dispatch code. >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
