RTEMS synchronization primitives support for SMP

[Gedare Bloom]

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.

> 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...

> 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