Gsoc2012: Atomic operation for RTEMS

Mon May 21 20:23:14 UTC 2012

On Mon, May 21, 2012 at 11:39 AM, yangwei weiyang <wei.a.yang at gmail.com> wrote:
> Hi all,
> After some research and analysis i think it is necessary to define all
> five types of generic functions. Because first two types atomic_load
> generic functions and atomic_store generic functions are basic atomic
> operations which is used to build some lock-less date and algorithms.
> The third type atomic_fetch-and-modify generic functions(like and,
> add, sub, or and xor) most of which are used to build some
> synchronization primitives should also be implemented. The fifth type
> atomic_compare_exchange generic functions is very important to build
> some synchronization primitives. Although the fourth type
> atomic_exchange generic functions is not defined by FreeBSD kernel but
> implemented by NetBSD, if this type is easy to be implemented we can
> consider define it.
>
> If this is ok for everyone i will start to define those type of
> functions in "rtems" style.
>
This sounds reasonable at first glance. You should determine what
layer of RTEMS interface these primitives are required, and what layer
of RTEMS can implement these operations. That will help you to decide
on the names for the interface functions, and also where you will be
implementing them.

My guess is the interface will be primarily internal at first
(something within score) and the implementation has to live in some
CPU-dependent layer such as libcpu. You can refer to the "cache
manager" for an idea of what I mean and how you might go about
implementing a split interface and implementation.

-Gedare

> 2012/5/20 yangwei weiyang <wei.a.yang at gmail.com>:
>> 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
>
>
>
> --
> Wei Yang
> Best Regards
>
> wei.a.yang at gmail.com
>
>
> --
> Wei Yang
> Best Regards
>
> wei.a.yang at gmail.com
>
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel