Gsoc2012: Atomic operation for RTEMS
chrisj at rtems.org
Fri May 18 00:38:51 UTC 2012
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
Agreed. This is a nice analysis.
> 2012/5/17 Chris Johns<chrisj at rtems.org>:
>> On 16/05/12 11:07 PM, Sebastian Huber wrote:
>>> 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.
>> rtems-devel mailing list
>> rtems-devel at rtems.org
More information about the devel