GSOC2013-Atomic Operations and SMP lock debug tool

Sebastian Huber sebastian.huber at
Fri Jun 7 11:26:10 UTC 2013

On 06/04/2013 04:53 PM, Deng Hengyi wrote:
> Hi Sebastian,
> 在 2013-6-4,下午10:28,Sebastian Huber <sebastian.huber at> 写道:
>> Hello Hengyi,
>> On 06/03/2013 05:11 PM, Deng Hengyi wrote:
>>> Hi Sebastian,
>>> 	In original the proposal of the atomic project there is a roadmap of switching to C11 atomic API completely along the time. So if the C11 is mature and used by RTEMS i am very glad to switch to it.
>> C11 is mature.  The question is if the GCC C11 support is mature enough (at least the features we are interested in).  According to wiki page GCC 4.7 was the first supporting C11 atomics.
>> I suppose we have to add a <stdatomic.h> to Newlib, e.g. the one from FreeBSD:
> Yeah, we should consider do this part of work in the meantime. And the now the FreeBSD uses Clang as its compile, but we can refer its implementation.

The <stdatomic.h> is now in Newlib.

>>> 	But i have some concern as below:
>>> 	1. Whether C11 support all the architecture used in RTEMS? (some architectures should not be supported if they are lack of atomic instructions)
>> I think the atomics are only interesting for RTEMS targets with SMP support.
> But if the atomic ops is used in score which is architecture-independent we should also provide its implementation (although not real atomic ops)
>>> 	2. If C11 does not support some architecture how to we make the atomic API unified?
>> If C11 support is not available for an architecture, then this is bad luck for the architecture vendor.
>>> 	3. Also should consider the UP mode support.
>> It is highly use case dependent if an UP mode makes sense.  If you have for example a spin lock used in task and interrupt context, then you have to ensure that the critical section is also protected by disabled interrupts.  Some lock-free list operations on the other hand may work for some architectures even without disabled interrupts.  In general operations performed by interrupts and tasks should be protected by disabled interrupts.  Thus the UP case is included anyway.
> In my option, we can use the exist atomic ops API and if the architecture atomic ops is supported by GCC C11 we can wrap its API into our atomic API, others remains no change. And this is also useful for the older GCC compliers maintained by developer.  And this switch way is  step by step.

It is all right to have an own API that can be easily implemented with the 
stuff from <stdatomic.h>.  We should make sure that this works for ARMv7, 
PowerPC, SPARC [1] and x86.

If someone uses a non C11 compiler, then he can implement this atomic API on 
its own as a fall back.

[1] I am not sure that the Leon core supports the GCC implementation.  The 
current cpusmplock.h contains a Leon specific feature (usage of non-cached 
address space).  GCC is definitely not aware of such a hack.

Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

More information about the users mailing list