About locks and concurrency rules for SMP systems

[Gedare Bloom]

On Thu, Mar 25, 2021 at 11:30 PM Richi Dubey <richidubey at gmail.com> wrote:
>
> Thanks for your quick response!
>
>> Each scheduler has its own lock. There are a couple of more locks involved.
>
> I understand.
>
> I backtracked a little and found that we have:
> _Thread_State_acquire_critical( the_thread, lock_context );
>
> to lock access to thread-specific variables.
>
> _Scheduler_Acquire_critical( scheduler, &lock_context
>
> to lock access to the current scheduler-specific data structures.
>
> What other locks do we have related to schedulers?
>

By definition, all locks relate to scheduling. The other major one
though would be _Thread_Dispatch_disable_critical and relatives like
_Thread_queue_Dispatch_disable, if you think of dispatching as part of
scheduling. However, the two operations are a little bit different.
Scheduling is selecting the next thread(s) to run, while dispatching
is actually making them run.


> On Wed, Mar 24, 2021 at 1:03 PM Sebastian Huber <sebastian.huber at embedded-brains.de> wrote:
>>
>> On 24/03/2021 08:07, Richi Dubey wrote:
>>
>> > How does RTEMS handle cases where two different cores access
>> > scheduler-related functions at the same time?
>> Each scheduler has its own lock. There are a couple of more locks involved.
>> > For ex., Can they access (or modify) the Scheduler_strong_APA_Context
>> > <https://git.rtems.org/rtems/tree/cpukit/include/rtems/score/schedulerstrongapa.h#n61>
>> > at the same time?
>> No, unless we have a bug.
>>
>> --
>> embedded brains GmbH
>> Herr Sebastian HUBER
>> Dornierstr. 4
>> 82178 Puchheim
>> Germany
>> email: sebastian.huber at embedded-brains.de
>> phone: +49-89-18 94 741 - 16
>> fax:   +49-89-18 94 741 - 08
>>
>> Registergericht: Amtsgericht München
>> Registernummer: HRB 157899
>> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
>> Unsere Datenschutzerklärung finden Sie hier:
>> https://embedded-brains.de/datenschutzerklaerung/
>>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel