Gsoc2012: Atomic operation for RTEMS

yangwei weiyang wei.a.yang at
Thu May 17 13:04:59 UTC 2012

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

2012/5/17 Chris Johns <chrisj at>:
> 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:
>> 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

Wei Yang
Best Regards

wei.a.yang at

More information about the devel mailing list