GSOC2013-Atomic Operations and SMP lock debug tool

[Deng Hengyi]

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. 

	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)
	2. If C11 does not support some architecture how to we make the atomic API unified？
	3. Also should consider the UP mode support.

在 2013-6-3，下午10:25，Sebastian Huber <sebastian.huber at embedded-brains.de> 写道：

> Hello Hengyi,
> 
> even though we have now an atomic operation API I think we should consider to use C11 instead.  The C11 standard is the first revision of the C standard that takes multiple threads and a memory model for it into account.  In pre C11 certain optimizations were allowed that are now forbidden (see also C11 "5.1.2.4 Multi-threaded executions and data races").
> 
> I would choose C11 as the implementation language for the RTEMS SMP port.
> 
> Instead of adding more features and support for the RTEMS specific atomic API we should instead add tests for the C11 <stdatomic.h> functions and ensure that everything we need is supported by the compiler and environment.
> 
> The GCC 4.8 is now the second major GCC revision supporting <stdatomic.h> so this should be stable enough.
> 
> On 06/02/2013 05:35 PM, Deng Hengyi wrote:
>> Hi all,
>> 
>> I am very glad to be accepted to do GSOC project by RTEMS. This is my second
>> year of GSOC for RTEMS. In the last year i proposal a project which intent to
>> support atomic operations for RTEMS.*
>> In the last year the architecture-independent atomic API has been developed and
>> the implementation of X86 and PowerPC has been completed. So in this year the
>> project’ [1] goal is to support all other architectures. The task includes that
>> a general atomic ops should be defined to support all the architectures which
>> do not support SMP mode. And in order to make RTEMS support SMP completely it
>> also should make the existing synchronization primitives SMP-safe, such as
>> semaphores, mutex, spinlocks and etc. But this task is complex and is hard to
>> debug. So in there I proposal a lock debug tool used to debug the lock problem,
>> like deadlock and recursive lock. And there is also a task about priority
>> inherence to be done. [2] is mail to complain its status.
>> *
>> *
>> 
>> *
>> *
>> If you have any comment please contact me freely.
>> *
> 
> 
> -- 
> 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 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