RTEMS synchronization primitives support for SMP

[wei.a.yang at gmail.com]

在 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 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
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel