Gsoc2012: Atomic operation for RTEMS
Gedare Bloom
gedare at rtems.org
Fri May 25 15:58:37 UTC 2012
On Fri, May 25, 2012 at 8:29 AM, yangwei weiyang <wei.a.yang at gmail.com> wrote:
> Hi all,
>
> This is a design draft for atomic operations API which needs your
> advices to make it better. The first part is a directory structure
> chart, atomic.h is API definition file and atomic_cpu.h is
> implementation file.
>
>
> |---/cpukit
> |
> |----score
> |
> |----include
> | |
> | -------rtems
> | | |
> | | ------score
> | | |
> | | ------atomic.h
> |---cpu
> | |
> | ------architecture
> | | |
> | | -------rtems
> | | |
> | | -------score
> | | |
> | | -------atomic_cpu.h
> | | |
> | | -------cpu.h
>
> Becuase most of the implementation of atomic operations are assembly
> instructions, if not they could also be implemented with inlilne C
> source code. So i place the architecture-independent atomic API
> definitions to the atomic.h which is visible to other rtems components
> like score, dirver and etc. The architecture-dependent atomic
> implementations are placed to the atomic_cpu.h which exists in every
> architecture-related directory as show above. The API is associated
> with implementations using method like this:
>
> for example, the atomic general load function API: int
> Atomic_Load_Acq_Int(volatile int *p)
>
> 1. In the implementation file atomic_cpu.h it will be implemented like this:
> static inline int _Atomic_Load_Acq_Int(volatile int *p)
> {
> embedded assembly code;
> };
This probably should be _CPU_Atomic_Load_acq_int(...)
Should it be defined in a .h file or in a .c file (or in a .S file)?
> 2. In the API definition file atomic.h it will be defined like this:
> #define Atomic_Load_Acq_Int(p) \
> _Atomic_Load_Acq_Int((volatile u_int *)(p))
This probably should be #define _Atomic_Load_acq_int(...)
> 3. The atomic_cpu.h should be included in the atomic.h directly or
> indirectly. If it is included in the atomic directly its file name
> should be fixed and each architecture has the same file name. If it is
> included in the atomic.h indirectly its file name can be unfixed and
> each architecture can have different file name, but it must be
> included by a architecture-dependent header file(like cpu.h as showed
> above) which can be included by architecture-independent score header
> file atomic.h
>
That sounds about right. I would prefer a fixed filename like
atomic_cpu.h. It can still be included through cpu.h though, or
through atomic.h. I'm not sure what the advantages or disadvantages
would be.
> Synopsis:
>
> The follow is atomic operation API definition in "rtems" style:
> 1. The atomic_store generic functions
> void _Atomic_Store_Rel_<_type_>(volatile _type_ *p, _type_ v);
Function names should be...
_API_Package_name_Method_name(...); where _API is omitted for most
internal interfaces. So this probably should be
_Atomic_Store_rel_<type>(...) or _CPU_Atomic_Store_rel_<type>. By the
way should we spell out "release" and "acquire" or stick to the
abbreviations as used by freebsd?
> 2. The atomic_load generic functions
> _type_ _Atomic_Load_Acq_<_type_>(volatile _type_ *p);
> 3. The atomic_fetch-and-modify generic functions
> void _Atomic_Fetch_Add_[Acq_|Rel_]<_type_>(volatile _type_ *p, _type_ v);
> void _Atomic_Fetch_Sub_[Acq_|Rel_]<_type_>(volatile _type_ *p, _type_ v);
> void _Atomic_Fetch_Or_[Acq_|Rel_]<_type_>(volatile _type_ *p, _type_ v);
> void _Atomic_Fetch_And_[Acq_|Rel_]<_type_>(volatile _type_ *p, _type_ v);
> 4. The atomic_compare_exchange generic functions
> int _Atomic_cmpset_[acq_|rel_]<_type_>(volatile _type_ *dst,
> _type_ old, _type_ new);
>
_Atomic_Cmpset_[acq_|rel_]<type>(...)
> Description:
>
> _types_:
>
> Each atomic operation operates on a specific type. The type to
> use is indicated in the function name. The available types that can be
> used are:
> int unsigned integer
> long unsigned long integer
> ptr unsigned integer the size of a pointer
> 32 unsigned 32-bit integer
> 64 unsigned 64-bit integer
> Because rtems is used in lots of soc with 8 or 16 bit bus, so some
> architectures can consider provide operations for types smaller than
> ``int''. In the FreeBSD only some architectures provide those types.
> char unsigned character
> short unsigned short integer
> 8 unsigned 8-bit integer
> 16 unsigned 16-bit integer
>
> Acq and Rel:
>
> "Acq" represens a read memory barrier which ensures that the
> effects of this operation are completed before the effects of any
> later data accesses
>
> "Rel" represens a write memory barrier which ensures that all
> effects of all previous data accesses are completed before this
> operation takes place
>
> If this design is passed by rtems developers i will post the two
> header files for being reviewed. Any comments will be welcoming. Thank
> you!
>
> 2012/5/22 <wei.a.yang at gmail.com>:
>> Yeah, I am also intend to refer the implementation of FreeBSD kernel directly as far as possible. Only if there are some special needs we can refer other implementations.
>>
>> 在 2012-5-22,15:22,Sebastian Huber <sebastian.huber at embedded-brains.de> 写道:
>>
>>> Hi,
>>>
>>> thanks for your really good overview.
>>>
>>> On 05/21/2012 05:39 PM, yangwei weiyang 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.
>>>
>>> I would focus more on the FreeBSD API since we currently port its network stack to RTEMS. FreeBSD has proven to provide competitive SMP performance thus its atomic API is capable enough.
>>>
>>> --
>>> Sebastian Huber, embedded brains GmbH
>>>
>>> Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
>>> Phone : +49 89 18 90 80 79-6
>>> Fax : +49 89 18 90 80 79-9
>>> E-Mail : sebastian.huber at embedded-brains.de
>>> PGP : Public key available on request.
>>>
>>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>>> _______________________________________________
>>> 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
>
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel
More information about the devel
mailing list