Gsoc2012: Atomic operation for RTEMS

Sun May 20 15:43:42 UTC 2012

Yeah, this is what i want to do at next step. From the analysis the
atomic API definition of the FreeBSD kernel and NetBSD kernel is
different. The FreeBSD kernel offers a way to perform atomic
operations in conjunction with a memory barrier. The atomic API
(ending with a memory barrier type) will guarantee that an atomic
operation will happen following some specified ordering with respect
to other memory accesses. However the NetBSD kernel defines the atomic
API and memory barrier API separately. That means the atomic
operations do not guarantee its atomicity operations will be visible
to other processor cores. You must explicitly use a memory barrier API
in conjunction with this atomic API if you want that an atomic
operation happen just after all other pending writes are completed. I
think the FreeBSD style is more better than NetBSD. So In principle we
should pick the FreeBSD atomic API but in an "rtems" style only if
FreeBSD is lack of some kind of atomic operation.

Ideally atomic operations (and memory barriers as well) should only be
used for building front-ending synchronization primitive (like locks)
and lock-less operations (in my opinion this scene should be
considered as next step). So it is necessary to know where the atomic
operations are used for building synchronization primitive. Below is
the case of FreeBSD.

FreeBSD kernel:
1. Mutexs
    int atomic_cmpset_[acq_|rel_]<type>(volatile _type_ *dst, _type_
old, _type_ new);
    void atomic_store_rel_<type>(volatile _type_ *p, _type_ v);
    void atomic_set_[acq_|rel_]<type>(volatile _type_ *p, _type_ v);
    void atomic_clear_[acq_|rel_]<type>(volatile _type_ *p, _type_ v);

2. Condition variables
    Do not use atomic API directly instead of using mutexs API.

3. Shared/Exclusive locks
    int atomic_cmpset_[acq_|rel_]<type>(volatile _type_ *dst, _type_
old, _type_ new);
    void atomic_store_rel_<type>(volatile _type_ *p, _type_ v);
    void atomic_set_[acq_|rel_]<type>(volatile _type_ *p, _type_ v);
    void atomic_clear_[acq_|rel_]<type>(volatile _type_ *p, _type_ v);

4. Semaphores
     Do not use atomic API directly instead of using mutexs and
condition variables API in conjunction.

5. Reader-Writer locks
    int atomic_cmpset_[acq_|rel_]<type>(volatile _type_ *dst, _type_
old, _type_ new);
    void atomic_store_rel_<type>(volatile _type_ *p, _type_ v);

6. Read-Mostly locks
    Do not use atomic API directly

7. Refcounts
    void atomic_add_[acq_|rel_]<type>(volatile _type_ *p, _type_ v);
    _type_ atomic_fetchadd_<type>(volatile _type_ *p, _type_ v);

Above is just a fuzzy analysis, maybe it is not comprehensive and
corrective. I just want to know where the atomic operations are used
in synchronization primitives. With respect to RTEMS its corresponding
synchronization primitives are like:
1. semaphore
2. message
3. event
4. mutexs
5. rwlock
6. spinlock
Maybe there will be other synchronization primitives to be added to
support SMP. So we can talk about which types of atomic operations
will be used by those synchronization primitives. Any suggestion are
welcome.

2012/5/18 Gedare Bloom <gedare at rtems.org>:
> 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

-- 
Wei Yang
Best Regards

wei.a.yang at gmail.com