Gsoc2012: Atomic operation for RTEMS
wei.a.yang at gmail.com
wei.a.yang at gmail.com
Tue Jun 5 00:47:34 UTC 2012
在 2012-6-4，23:43，Gedare Bloom <gedare at rtems.org> 写道：
> two comments:
>
> 1) Function names should only capitalize the first letter of the first
> word of the package name and the method name, so for example
> _Atomic_Fetch_Add_int
> should be
> _Atomic_Fetch_add_int
Thanks for your comment.
>
> 2) Are the types ATOMIC_xxx part of the bsd types or are they rtems
> types? If rtems types then I think they should just be Atomic_xxx.
>
They are Rtems types, I will change them to Atomic_xxx.
> -Gedare
>
> On Mon, Jun 4, 2012 at 11:10 AM, yangwei weiyang <wei.a.yang at gmail.com> wrote:
>> Hi all,
>>
>> Recently i have submitted some source code to my github repository[1].
>> And the API design also have a little different from the past
>> discussion.
>> Firstly i adopted the same design strategy as cache manager in the
>> rtems. The file cpukit/score/src/atomic_manager.c was added which is a
>> wrapper of architecture-dependent atomic implementations. The atomic
>> operation interface definition add a additional option which specified
>> the memory order in the atomic operations. This way can be compatible
>> with C1X in the future. But the implementation should reuse the
>> FreeBSD kernel atomic implementations as far as possible which will be
>> adopted with atomic API by atomic_manager.c.
>> Any comments are welcome.
>>
>> [1].https://github.com/WeiY/rtems
>>
>> 2012/5/30 yangwei weiyang <wei.a.yang at gmail.com>:
>>> Hi all,
>>>
>>> I have submitted my source code to my rtems repository on the github.
>>> Recently i just add two files: atomic.h and atomic_cpu.h for i386. In
>>> the atomic.h i just define some parts of atomic operations API and in
>>> the atomic_cpu.h i just typedef some atomic date type used by the
>>> atomic API. As discussed in the list each atomic operation API is
>>> associated with memory barrier(_acq_ or _rel_) and date type(int,
>>> long, 32, 64 and so), so the amount of API is a little more.
>>> Please help review my code and giving your comments is very welcome. Thank you!
>>>
>>> atomic.h:
>>> https://github.com/WeiY/rtems/blob/70c825d98750606619c9a21159abec327ac020f1/cpukit/score/include/rtems/score/atomic.h
>>> atomic_cpu.h:
>>> https://github.com/WeiY/rtems/blob/70c825d98750606619c9a21159abec327ac020f1/cpukit/score/cpu/i386/rtems/score/atomic_cpu.h
>>>
>>> 2012/5/30 <wei.a.yang at gmail.com>:
>>>>
>>>> 在 2012-5-30，7:52，Gedare Bloom <gedare at rtems.org> 写道：
>>>>
>>>>> On Sat, May 26, 2012 at 11:10 PM, <wei.a.yang at gmail.com> wrote:
>>>>>>
>>>>>> 在 2012-5-25，23:58，Gedare Bloom <gedare at rtems.org> 写道：
>>>>>>
>>>>>>> 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)?
>>>>>>>
>>>>>> The CPU prefix looks good for me. I think a .h file is just enough. Because most of codes are embedded assembly codes and the .h file can be included by API header file atomic.h
>>>>>>>> 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(...)
>>>>>> Do you mean #define Atomic_Load_acq_int(p) _CPU_Atomic_Load_acq_int((volatile int *)(p))?
>>>>> I'm not sure the use of the Atomic_Load_acq_int versus
>>>>> _CPU_Atomic_Load_acq_int please clarify why there are two symbols for
>>>>> the same thing.
>>>>>
>>>> In my first thought I wanted to use the first symbol exported to other components of Rtems, and the second symbol was used to implement the atomic for many architectures. Those two symbols seems a little clearly to separated the interface and implementation. But when I write the codes I find these two symbols are really redundantly. So I think just one symbol is enough and in the interface definition file we just external the symbol.
>>>>>>>
>>>>>>>> 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
>>>
>>>
>>>
>>> --
>>> Wei Yang
>>> Best Regards
>>>
>>> wei.a.yang at gmail.com
>>
>>
>>
>> --
>> Wei Yang
>> Best Regards
>>
>> wei.a.yang at gmail.com
More information about the devel
mailing list