<html><head></head><body bgcolor="#FFFFFF"><div><br></div><div>在 2012-8-8，23:00，Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>> 写道：<br><br></div><div></div><blockquote type="cite"><div><br><br><div class="gmail_quote">On Wed, Aug 8, 2012 at 10:24 AM, yangwei weiyang <span dir="ltr"><<a href="mailto:wei.a.yang@gmail.com" target="_blank">wei.a.yang@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2012/8/6 Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>>:<br>
<div><div class="h5">> On Mon, Aug 6, 2012 at 9:31 AM, yangwei weiyang <<a href="mailto:wei.a.yang@gmail.com">wei.a.yang@gmail.com</a>> wrote:<br>
>> Hi all,<br>
>> As a GSOC project "atomic operations support for RTEMS" has completed<br>
>> first milestone which includes atomic API design and its<br>
>> implementation for i386 and PowerPC architecture (PowerPC atomic was<br>
>> not tested under SMP mode). And then i want to do more developments<br>
>> based on this project. The basic idear is to make existing kinds of<br>
>> synchronization primitives on RTEMS support SMP and to add some new<br>
>> SMP-safe synchronization primitives based on atomic operations.<br>
>> And in there i attach the FreeBSD synchronization primitives which are<br>
>> based on atomic operations:<br>
>> FreeBSD kernel:<br>
>> 1. Mutexs<br>
>> int atomic_cmpset_[acq_|rel_]<type>(volatile _type_ *dst,<br>
>> _type_old, _type_ new);<br>
>> void atomic_store_rel_<type>(volatile _type_ *p, _type_ v);<br>
>> void atomic_set_[acq_|rel_]<type>(volatile _type_ *p, _type_ v);<br>
>> void atomic_clear_[acq_|rel_]<type>(volatile _type_ *p, _type_ v);<br>
>><br>
>> 2. Condition variables<br>
>> Do not use atomic API directly instead of using mutexs API.<br>
>><br>
>> 3. Shared/Exclusive locks<br>
>> int atomic_cmpset_[acq_|rel_]<type>(volatile _type_ *dst,<br>
>> _type_old, _type_ new);<br>
>> void atomic_store_rel_<type>(volatile _type_ *p, _type_ v);<br>
>> void atomic_set_[acq_|rel_]<type>(volatile _type_ *p, _type_ v);<br>
>> void atomic_clear_[acq_|rel_]<type>(volatile _type_ *p, _type_ v);<br>
>><br>
>> 4. Semaphores<br>
>> Do not use atomic API directly instead of using mutexs and<br>
>> condition variables API in conjunction.<br>
>><br>
>> 5. Reader-Writer locks<br>
>> int atomic_cmpset_[acq_|rel_]<type>(volatile _type_ *dst,<br>
>> _type_old, _type_ new);<br>
>> void atomic_store_rel_<type>(volatile _type_ *p, _type_ v);<br>
>><br>
>> 6. Read-Mostly locks<br>
>> Do not use atomic API directly<br>
>><br>
>> 7. Refcounts<br>
>> void atomic_add_[acq_|rel_]<type>(volatile _type_ *p, _type_ v);<br>
>> _type_ atomic_fetchadd_<type>(volatile _type_ *p, _type_ v);<br>
>><br>
>> RTEMS existing synchronization primitives:<br>
>> 1. semaphore<br>
>> 2. message<br>
>> 3. event<br>
>> 4. mutexs<br>
>> 5. rwlock<br>
>> 6. spinlock<br>
>> So i have two questions:<br>
>> 1. which primitives above should be modified to support SMP?<br>
> Probably any of these. Construct a plan to update the existing<br>
> primitives and to decide how to split the implementations between uni<br>
> and SMP versions.<br>
><br>
</div></div>The objective is to make the above primitives SMP safely and the main<br>
work is to replace the atomic operations in the above primitives with<br>
atomic functions. And the atomic operation for RTEMS is designed to be<br>
compatible with UP and SMP versions. So there is no need to worry<br>
about it.<br>
I have studied some codes of the above primitives in RTEMS, in the<br>
source code of most primitives there are some codes to load and modify<br>
some public variables which in current version it uses "_ISR_Disable"<br>
to protect it. So this part of code should be updated using atomic<br>
operations. Later i will list those parts of code in detail.<br>
<div class="im"><br></div></blockquote><div>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.<br>
<br></div></div></div></blockquote>Yeah, for the architecture which does not support SMP currently we just use ISR_Disable to implement atomic operations, and then replace the ISR_Disable in the synchronization primitives with atomic operations, that will make sync primitives workable for both UP and SMP. <div><br></div><div><blockquote type="cite"><div><div class="gmail_quote"><div>-Gedare<br><br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">
>> 2. what kinds of new primitives should be added to support SMP more better?<br>
> I'm not sure, we would have to study this more deeply. A first guess<br>
> is some kind of RCU locks. A review of the locks most often used for<br>
> SMP would be helpful, and of the various lock-free algorithms that<br>
> might be useful...<br>
</div>Yeah, about this question i think we can refer what FreeBSD do in the<br>
SMPng project. There are some reference materials.<br>
1. <a href="http://2009.asiabsdcon.org/papers/abc2009-P6A-paper.pdf" target="_blank">http://2009.asiabsdcon.org/papers/abc2009-P6A-paper.pdf</a><br>
2. <a href="http://www.freebsd.org/smp/" target="_blank">http://www.freebsd.org/smp/</a><br>
3. <a href="https://doc.bsdgroup.de/doc/de/books/arch-handbook/smp.html" target="_blank">https://doc.bsdgroup.de/doc/de/books/arch-handbook/smp.html</a><br>
<div class="HOEnZb"><div class="h5">><br>
>> If you have any comments please contact me freely.<br>
>><br>
>><br>
>> --<br>
>> Wei Yang<br>
>> Best Regards<br>
>><br>
>> wei.a.yang at <a href="http://gmail.com" target="_blank">gmail.com</a><br>
>> _______________________________________________<br>
>> rtems-devel mailing list<br>
>> <a href="mailto:rtems-devel@rtems.org">rtems-devel@rtems.org</a><br>
>> <a href="http://www.rtems.org/mailman/listinfo/rtems-devel" target="_blank">http://www.rtems.org/mailman/listinfo/rtems-devel</a><br>
<br>
<br>
<br>
--<br>
Wei Yang<br>
Best Regards<br>
<br>
wei.a.yang at <a href="http://gmail.com" target="_blank">gmail.com</a><br>
</div></div></blockquote></div><br>
</div></blockquote></div></body></html>