Gsoc2012: Atomic operation for RTEMS

[Chris Johns]

On 17/05/12 11:04 PM, yangwei weiyang wrote:
> I agree that the ISO C1X atomic definitions are not stable enough to
> be used now. Although the latest gcc and clang compiler have support
> C1X atomic feature there are not many applications using this feature.
> About the atomic API defined by C1X i think its definitions are not
> all well and applicable for RTEMS. C1X atomic API is classified very
> well, but its API is designed for specification and compatibility, not
> every API is optimal for us.  So we do not need to design the every
> API compatible with the C1X specification.
>
> About the user of atomic API i think the first main user is RTEMS
> kernel, like synchronization primitives and lock-free algorithm. Most
> of time the application should not use the atomic API directly instead
> of using the other primitives based on atomic operations. In my
> opinion firstly we can analysis the RTEMS synchronization primitives
> and know what atomic operations will be used by them, this will be
> used for API design. So we can refer the FreeBSD and NetBSD kernel
> implementation.

Agreed. This is a nice analysis.

Chris

>
> 2012/5/17 Chris Johns<chrisj at rtems.org>:
>> On 16/05/12 11:07 PM, Sebastian Huber wrote:
>>>
>>> Hi,
>>>
>>> thanks for your nice overview about some existing atomic APIs. I am no
>>> longer of the option to use the<stdatomic.h>  facility to implement the
>>> SMP locks on RTEMS. Too much is controlled internally by the compiler.
>>> Also the results on PowerPC are not optimal from my point of view:
>>>
>>> http://gcc.gnu.org/ml/gcc-help/2012-03/msg00377.html
>>>
>>> Who will be the user of this atomic API?
>>>
>>
>> This is a key question and one which makes the this area of work complicated
>> in the future. RTEMS is both the kernel and application and this means the
>> atomic operations API we provide for the kernel to use and that provided by
>> a standard language feature need to co-exist.
>>
>> Personally I am not convinced C++ is the best place to depend on this type
>> of thing and I would be rather cautious before committing an application
>> development to it. Yes the API makes the code portable and the functionality
>> stable across platforms, how-ever everyone needs to get to that point first
>> and specifically the compiler writers before it is true. I have only ever
>> developed a couple of fully C++ embedded applications. Most are a mixture of
>> C and C++ and that is one area I am not sure about. RTEMS needs to provide
>> support to C applications.
>>
>> RTEMS has to support the C++ standard but do we need to do this now ? I
>> agree with you we should develop our own kernel level API and provide it as
>> an RTEMS API, ie following the classic API. How this relates to the C++
>> support in the future can be visited one we have something our C based
>> kernel can use.
>>
>> Chris
>>
>> _______________________________________________
>> rtems-devel mailing list
>> rtems-devel at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-devel
>
>
>