RTEMS synchronization primitives support for SMP

[Chris Johns]

On 9/08/12 2:33 PM, wei.a.yang at gmail.com wrote:
> 
> 在 2012-8-9，9:23，Chris Johns <chrisj at rtems.org> 写道：
> 
>> On 9/08/12 10:47 AM, wei.a.yang at gmail.com wrote:
>>>
>>>>     The objective is to make the above primitives SMP safely and the main
>>>>     work is to replace the atomic operations in the above primitives with
>>>>     atomic functions. And the atomic operation for RTEMS is designed to be
>>>>     compatible with UP and SMP versions. So there is no need to worry
>>>>     about it.
>>>>     I have studied some codes of the above primitives in RTEMS, in the
>>>>     source code of most primitives there are some codes to load and modify
>>>>     some public variables which in current version it uses "_ISR_Disable"
>>>>     to protect it. So this part of code should be updated using atomic
>>>>     operations. Later i will list those parts of code in detail.
>>>>
>>>> The advantage of ISR_Disable for UP is that every architecture
>>>> supports it. In order to replace ISR_Disbable in general we would need
>>>> generic atomic operations on every rtems target. But maybe a staged
>>>> update of the synchronization primitives does make sense, or even
>>>> implementing "atomic operations" that rely on ISR_Disable for the
>>>> architectures in which we do not yet have true atomic support.
>>>>
>>> Yeah, for the architecture which does not support SMP currently we just
>>> use ISR_Disable to implement atomic operations, and then replace the
>>> ISR_Disable in the synchronization primitives with atomic operations,
>>> that will make sync primitives workable for both UP and SMP.
>>
>> I am still unclear about the path.
>>
>> Are you saying the atomic operations will be used in the code and in architectures that are UP or lack support the atomic primitives will be ISR disable and enables ?
> For the UP architecture which is also lack of atomic instructions support the atomic operations can be simulated using ISR disable and enable, but this parts of codes are implemented in the architecture-dependent layer not score layer.
>>
>> Is it normal to do this with atomic primitives ?
>>
> I think atomic primitives are both useful for UP and SMP, but ISR disable is just useful for UP to protect share data. So the core support should use atomic primitives and atomic determines whether use ISR disable/enable or not.

I am concerned about how the code reads. If I see an atomic primitive
written in the score I would expect it to implement that and not to map
to something else. Mapping atomic primitives to ISR enable/disable is
not what I would expect. I feel we should be explicit about our usage
rather than hiding ISR enable and disable logic in the arch dependent
layer of the atomic code.

I am also unsure what ISR disable and enable buys us in the atomic API.
On a UP if we need to disable interrupts in atomic locks that implies
nesting is occurring via interrupts. I am currently not sure how
interrupt are implemented on an SMP system and what is proposed and how
the atomic locks relate to critical sections.

Chris

>> I am concerned with the layering. Should the core support be based on a set of core operations and those are either the atomic primitives or ISR disable/enable ? This make the selection the core's.
>>