atomic support for RTEMS

Deng Hengyi wei.a.yang at gmail.com
Tue Apr 2 15:41:15 UTC 2013


yeah, recently i am doing this work. I have found some architectures like ARM, before ARMV6 there is no really atomic instruction and after ARMV6 it has support ll/sc atomic instruction. But for unprocessor which really has its own atomic instruction the cost of atomic instruction is also heavier than general atomic ops(Disable/Enable ISR), So in my option we should implement the general atomic ops for all unprocessor or unprocessor mode(some SMP-enable architecture). And then port the available atomic ops for SMP-mode architecture in the BSD or Linux to RTEMS. A guide is a must material should be provided.

WeiY
  
在 2013-4-2,下午11:06,Gedare Bloom <gedare at rtems.org> 写道:

> Overall this looks good. Try to find which of the architectures in
> RTEMS we want to support, and whether they have the atomic ops
> available in FreBSD or OpenBSD, or where. Also, develop a guide for
> doing the update to latest upstream as part of this work if there is
> not already a guide available.
> 
> -Gedare
> 
> On Tue, Apr 2, 2013 at 10:25 AM, Deng Hengyi <wei.a.yang at gmail.com> wrote:
>> Hi, all
>> 
>> The project atomic support for RTEMS a GSOC2012 proposal which implemented architecture-independent API design and two architecture X86 and powerpc support. This year i will continue to doing more work to implement this project. The main tasks include:
>> 
>> 1. implement a series of general atomic ops for unprocesse.
>>   As we know the atomic instruction has performence cost because of costs of cache misses. There is a picture which list atomic instruction costs. The atomic instruction introduces instruction execution uncertainty. So if the architecture does not support SMP mode it should use general atomic ops which rely the Disable/Enable-IRQ method.
>> 2. support atomic primitive for more architectures like ARM,MIPS,SPARC,etc.
>>   If the architecture supports SMP mode(define macro RTEMS_SMP)it will use its own atomic hardware instruction, otherwise it will use general atomic ops.
>> 3. update atomic implementation with the latest freebsd(the powerpc and x86 implementation is ported from freebsd).
>> 4. make existing kinds of synchronization primitives on RTEMS support SMP and to add  some new SMP-safe synchronization primitives based on atomic operations.
>>   RTEMS existing synchronization primitives:
>>   1. semaphore
>>   2. message
>>   3. event
>>   4. mutexs
>>   5. rwlock
>>   6. spinlock
>> 5. If possible i want to implement some lock-free algorithms or data structures based on atomic ops.
>> 
>> This just my preliminary ideas if you have any comment and requirement please repley freely.
>> _______________________________________________
>> rtems-devel mailing list
>> rtems-devel at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-devel





More information about the devel mailing list