Gsoc2012: Atomic operation for RTEMS

[Gedare Bloom]

I'd suggest picking one of the *Bsd atomics and clone their interface
but in an "rtems" style. the implementation can be borrowed directly
from them.

Choosing which interface to copy should be done with some care and
thought and be justified based on how we will use the atomic
operations.

-Gedare

On Thu, May 17, 2012 at 8:38 PM, Chris Johns <chrisj at rtems.org> wrote:
> 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
>>
>>
>>
>>
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel