Gsoc2012: Atomic operation for RTEMS
yangwei weiyang
wei.a.yang at gmail.com
Fri May 25 12:29:21 UTC 2012
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;
};
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))
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
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);
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);
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
More information about the devel
mailing list