RTEMS synchronization primitives support for SMP

[Gedare Bloom]

On Wed, Aug 8, 2012 at 10:24 AM, yangwei weiyang <wei.a.yang at gmail.com>wrote:

> 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.
>
> The advantage of ISR_Disable for UP is that every architecture supports
it. In order to replace ISR_Disbable in general we would need generic
atomic operations on every rtems target. But maybe a staged update of the
synchronization primitives does make sense, or even implementing "atomic
operations" that rely on ISR_Disable for the architectures in which we do
not yet have true atomic support.

-Gedare



> >> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20120808/1be9a3ff/attachment-0001.html>