RTEMS synchronization primitives support for SMP

[yangwei weiyang]

2012/8/6 Gedare Bloom <gedare at rtems.org>:
> On Mon, Aug 6, 2012 at 9:31 AM, yangwei weiyang <wei.a.yang at gmail.com> wrote:
>> Hi all,
>> As a GSOC project "atomic operations support for RTEMS" has completed
>> first milestone which includes atomic API design and its
>> implementation for i386 and PowerPC architecture (PowerPC atomic was
>> not tested under SMP mode). And then i want to do more developments
>> based on this project. The basic idear is to make existing kinds of
>> synchronization primitives on RTEMS support SMP and to add  some new
>> SMP-safe synchronization primitives based on atomic operations.
>> And in there i attach the FreeBSD synchronization primitives which are
>> based on atomic operations:
>> FreeBSD kernel:
>> 1. Mutexs
>>     int atomic_cmpset_[acq_|rel_]<type>(volatile _type_ *dst,
>> _type_old, _type_ new);
>>     void atomic_store_rel_<type>(volatile _type_ *p, _type_ v);
>>     void atomic_set_[acq_|rel_]<type>(volatile _type_ *p, _type_ v);
>>     void atomic_clear_[acq_|rel_]<type>(volatile _type_ *p, _type_ v);
>>
>> 2. Condition variables
>>     Do not use atomic API directly instead of using mutexs API.
>>
>> 3. Shared/Exclusive locks
>>     int atomic_cmpset_[acq_|rel_]<type>(volatile _type_ *dst,
>> _type_old, _type_ new);
>>     void atomic_store_rel_<type>(volatile _type_ *p, _type_ v);
>>     void atomic_set_[acq_|rel_]<type>(volatile _type_ *p, _type_ v);
>>     void atomic_clear_[acq_|rel_]<type>(volatile _type_ *p, _type_ v);
>>
>> 4. Semaphores
>>      Do not use atomic API directly instead of using mutexs and
>> condition variables API in conjunction.
>>
>> 5. Reader-Writer locks
>>     int atomic_cmpset_[acq_|rel_]<type>(volatile _type_ *dst,
>> _type_old, _type_ new);
>>     void atomic_store_rel_<type>(volatile _type_ *p, _type_ v);
>>
>> 6. Read-Mostly locks
>>     Do not use atomic API directly
>>
>> 7. Refcounts
>>     void atomic_add_[acq_|rel_]<type>(volatile _type_ *p, _type_ v);
>>     _type_ atomic_fetchadd_<type>(volatile _type_ *p, _type_ v);
>>
>> RTEMS existing synchronization primitives:
>> 1. semaphore
>> 2. message
>> 3. event
>> 4. mutexs
>> 5. rwlock
>> 6. spinlock
>> So i have two questions:
>> 1. which primitives above should be modified to support SMP?
> Probably any of these. Construct a plan to update the existing
> primitives and to decide how to split the implementations between uni
> and SMP versions.
>
The objective is to make the above primitives SMP safely and the main
work is to replace the atomic operations in the above primitives with
atomic functions. And the atomic operation for RTEMS is designed to be
compatible with UP and SMP versions. So there is no need to worry
about it.
I have studied some codes of the above primitives in RTEMS, in the
source code of most primitives there are some codes to load and modify
some public variables which in current version it uses "_ISR_Disable"
to protect it. So this part of code should be updated using atomic
operations. Later i will list those parts of code in detail.

>> 2. what kinds of new primitives should be added to support SMP more better?
> I'm not sure, we would have to study this more deeply. A first guess
> is some kind of RCU locks. A review of the locks most often used for
> SMP would be helpful, and of the various lock-free algorithms that
> might be useful...
Yeah, about this question i think we can refer what FreeBSD do in the
SMPng project. There are some reference materials.
1. http://2009.asiabsdcon.org/papers/abc2009-P6A-paper.pdf
2. http://www.freebsd.org/smp/
3. https://doc.bsdgroup.de/doc/de/books/arch-handbook/smp.html
>
>> If you have any comments please contact me freely.
>>
>>
>> --
>> Wei Yang
>> Best Regards
>>
>> wei.a.yang at gmail.com
>> _______________________________________________
>> 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