Project about Atomic Operations

[Joel Sherrill]

On 03/26/2012 11:00 AM, Yang Wei wrote:
>
> 在 2012-3-26，23:45，Sebastian Huber<sebastian.huber at embedded-brains.de>  写道：
>
>> On 03/26/2012 05:32 PM, Gedare Bloom wrote:
>>> Maybe we should design our API to be at least a superset of what the
>>> compiler must provide for C11 compliance. Target architectures /
>>> compilers that do not support the C11 atomics will need the atomic
>>> operations implemented in assembly language. For targets that are
>>> supported the API will thinly wrap the C-language atomic features and
>>> can share code.
>> This is reinventing the wheel.  I don't see why we need the 100th atomic library.
>>
> The C11 support for atomic primitive since 2011. Whether the compiler like gcc has support all the atomic primitives and for all architectures? And Rtems does not use standard library provided by compiler, so we still support all the atomic primitives on the newlib. There are also lots of work to do if we support all the atomic primitives defined by C11 standard
GCC 4.7 is making progress. There is the P99 collection:

http://p99.gforge.inria.fr/p99-html/group__atomic.html

and this:

http://svnweb.freebsd.org/base/head/include/stdatomic.h?view=markup

which claims to support three different types of compilers:

+ Clang 3.1's atomic intrinsics (not released yet)
+ GCC 4.7's atomic intrinsics
+ GCC's __sync interface

I don't know if clang 3.1 has been released but gcc 4.7 has been released
since the description of stdatomic.h was written.

FWIW there is also the small set of TAS, CMP/SWP type operations
used in the shmdr in RTEMS. Updating those would be an appropriate
part of this task.

But in general, my concern for all of this is what are the use cases
from RTEMS perspective.

+ Is it only for SMP or AMP use?

+ MP as in shared memory MP found in RTEMS for years. Kernel locks in 
[AS]MP?

+ Is there a uniprocessor use case?

Off the top of my head, I have trouble seeing how stdatomic.h
wouldn't be a good starting spot for RTEMS for kernel locking.

If we are generalizing all SMP/CPU interface points, then the
idea of current CPU core is another thing to consider.
>> -- 
>> 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-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users


-- 
Joel Sherrill, Ph.D.             Director of Research&   Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
     Support Available             (256) 722-9985


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20120326/70d63700/attachment-0001.html>