RTEMS synchronization primitives support for SMP

[Chris Johns]

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 ?

Is it normal to do this with atomic primitives ?

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.

Chris