<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">2014-03-04 21:32 GMT+08:00 Gedare Bloom <span dir="ltr"><<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">On Mon, Mar 3, 2014 at 7:51 PM, zhang json <<a href="mailto:json.a.zhang@gmail.com">json.a.zhang@gmail.com</a>> wrote:<br>
> Dear all,<br>
><br>
> Recently i have been study the RTEMS code and all related resource about<br>
> condition variables. At the meantime i am preparing a proposal for this GSOC<br>
> project. Although it is just a skeleton draft, i think it is better to throw<br>
> it ASAP. So that everyone can give me some valuable suggestions. And my<br>
> proposal is managed by github, so if you have any comments you can just open<br>
> a new issue to me. Waiting for all your comments! Thank you!<br>
><br>
> <a href="https://github.com/cloud-hot/proposal" target="_blank">https://github.com/cloud-hot/proposal</a><br>
><br>
</div>Please add yourself and the link to your proposal to the table at<br>
<a href="http://wiki.rtems.org/wiki/index.php/RTEMSSummerOfCode#Students.27_Proposals" target="_blank">http://wiki.rtems.org/wiki/index.php/RTEMSSummerOfCode#Students.27_Proposals</a><br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div>Done+</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
><br>
><br>
> 2014-03-04 8:42 GMT+08:00 zhang json <<a href="mailto:json.a.zhang@gmail.com">json.a.zhang@gmail.com</a>>:<br>
><br>
>> Hi Sebastian,<br>
>><br>
>> Thank you for your reply!<br>
>><br>
>> 2014-03-03 15:06 GMT+08:00 Sebastian Huber<br>
>> <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>>:<br>
>><br>
>>> On 2014-03-02 03:40, zhang json wrote:<br>
>>>><br>
>>>><br>
>>>> 2014-02-28 15:15 GMT+08:00 Sebastian Huber<br>
>>>> <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a><br>
>>>> <mailto:<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>>>:<br>
>>>><br>
>>>><br>
>>>> On 2014-02-28 01:12, zhang json wrote:<br>
>>>><br>
>>>><br>
>>>> 2014-02-26 1:07 GMT+08:00 Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a><br>
>>>> <mailto:<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>><br>
>>>> <mailto:<a href="mailto:gedare@rtems.org">gedare@rtems.org</a> <mailto:<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>>>>:<br>
>>>><br>
>>>><br>
>>>><br>
>>>> You may like to read<br>
>>>><br>
>>>> <a href="http://wiki.rtems.org/wiki/__index.php/SMP#Non-Preempt___Mode_for_Mutual_Exclusion" target="_blank">http://wiki.rtems.org/wiki/__index.php/SMP#Non-Preempt___Mode_for_Mutual_Exclusion</a><br>
>>>><br>
>>>><br>
>>>> <<a href="http://wiki.rtems.org/wiki/index.php/SMP#Non-Preempt_Mode_for_Mutual_Exclusion" target="_blank">http://wiki.rtems.org/wiki/index.php/SMP#Non-Preempt_Mode_for_Mutual_Exclusion</a>><br>
>>>> in addition to the Condition Variables project page. You<br>
>>>> can search<br>
>>>> for "condition variable" in a search engine to get some<br>
>>>> useful<br>
>>>> background material. More below.<br>
>>>><br>
>>>> Thank you for your reply. I will search and prepare this project<br>
>>>> and a<br>
>>>> draft<br>
>>>> will be post ASAP.<br>
>>>><br>
>>>> On Tue, Feb 25, 2014 at 9:45 AM, zhang json<br>
>>>> <<a href="mailto:json.a.zhang@gmail.com">json.a.zhang@gmail.com</a> <mailto:<a href="mailto:json.a.zhang@gmail.com">json.a.zhang@gmail.com</a>><br>
>>>> <mailto:<a href="mailto:json.a.zhang@gmail.com">json.a.zhang@gmail.com</a><br>
>>>> <mailto:<a href="mailto:json.a.zhang@gmail.com">json.a.zhang@gmail.com</a>>__>><br>
>>>><br>
>>>> wrote:<br>
>>>> > Hi all,<br>
>>>> ><br>
>>>> > I am a student who is preparing for participating the<br>
>>>> GSOC2014, and from<br>
>>>> > 'Open Project' i found a interesting project 'Condition<br>
>>>> Variables'. So i<br>
>>>> > want to know the basic information about the status of<br>
>>>> this<br>
>>>> project.<br>
>>>> ><br>
>>>> > There is a bug [1] which is maybe related to it but it<br>
>>>> seems that<br>
>>>> > 'Condition Variables' is not the main problem of this<br>
>>>> bug. So<br>
>>>> my confusion<br>
>>>> > is blow:<br>
>>>> ><br>
>>>> > 1. As one of the classic operating system<br>
>>>> synchronization<br>
>>>> primitives whether<br>
>>>> > RTEMS has a basic 'Condition Variables' support?<br>
>>>> RTEMS lacks a condition variable (monitor) implementation<br>
>>>> within the<br>
>>>> classic API located in cpukit/rtems/*, and also within the<br>
>>>> supercore<br>
>>>> "kernel" interface located in cpukit/score/*. There is<br>
>>>> condition<br>
>>>> variables support in posix, as the<br>
>>>> cpukit/posix/include/rtems/__posix/condimpl.h.<br>
>>>><br>
>>>><br>
>>>> OK, i have some rtems experience so i will first design the CV<br>
>>>> and<br>
>>>> implement it<br>
>>>> in score component, then warp it into classic api.<br>
>>>><br>
>>>><br>
>>>> We already have a CV implementation in RTEMS. It is currently only<br>
>>>> available for the PThread API. What we need is a definition for the<br>
>>>> Classic API and a shared implementation. We should also address<br>
>>>> potential<br>
>>>> priority inversion issues of CV in combination with priority based<br>
>>>> schedulers.<br>
>>>><br>
>>>> Could you tell me where i can find the code of CV implementation for the<br>
>>>> Pthread API? and CV is also implemented in the score? then needed work<br>
>>>> is to<br>
>>>> implement a classic API for CV and shared its implementation?<br>
>>><br>
>>><br>
>>> Answering this question gives you a good opportunity to discover the<br>
>>> RTEMS sources.<br>
>>><br>
>> Yeah, recently i have been studying the RTEMS code.<br>
>><br>
>>>><br>
>>>><br>
>>>> > 2. If answer not from 1, what is the requirement of the<br>
>>>> implementation?<br>
>>>> It should implement a classic API condition variable that<br>
>>>> can be<br>
>>>> similar to the classic API implementation of semaphore<br>
>>>> (cpukit/rtems/include/rtems/__rtems/sem.h and semimpl.h).<br>
>>>> The<br>
>>>><br>
>>>> condition<br>
>>>> variable should be implemented in the supercore<br>
>>>> (cpukit/score) and<br>
>>>> that implementation should be shared by the posix condvar<br>
>>>> and the<br>
>>>> classic API condition variables.<br>
>>>><br>
>>>> Yeah, i will refer to implementation of semaphore and mutex. And<br>
>>>> there<br>
>>>> are lots<br>
>>>> of open source CV implementation for many os, such freebsd,<br>
>>>> netbsd, linux,<br>
>>>> eCos. About linux its license may be is not compatible with<br>
>>>> RTEMS, so i<br>
>>>> just<br>
>>>> learn its idea instead of code.<br>
>>>><br>
>>>> > 3. Whether its implementation should support SMP?<br>
>>>> ><br>
>>>> The implementation must support SMP.<br>
>>>><br>
>>>> Yeah, it will be a challenge. But as i know the SMP support of<br>
>>>> RTEMS is<br>
>>>> becoming better, some SMP synchronization primitives have been<br>
>>>> support,<br>
>>>> like<br>
>>>> atomic. I am wondering whether semaphore and mutex is supported<br>
>>>> SMP?<br>
>>>><br>
>>>><br>
>>>> The SMP support in RTEMS is currently based on a Giant lock. So<br>
>>>> most<br>
>>>> objects simply work.<br>
>>>><br>
>>>> And in the future should the Giant lock be removed? so now should we<br>
>>>> consider<br>
>>>> this situation, or we can first use Giant lock and then replace it with<br>
>>>> other<br>
>>>> safe lock later.<br>
>>><br>
>>><br>
>>> Yes, the Giant lock must be removed to get a real-time operating system<br>
>>> that can compete on the market. Removing the Giant lock is however a major<br>
>>> challenge and beyond a GSoC project.<br>
>>><br>
>>> <a href="http://www.rtems.org/wiki/index.php?title=SMP#Fine_Grained_Locking" target="_blank">http://www.rtems.org/wiki/index.php?title=SMP#Fine_Grained_Locking</a><br>
>>><br>
>> Maybe i can consider it as a future work after GSOC project.<br>
>><br>
>>><br>
>>><br>
>>> --<br>
>>> Sebastian Huber, embedded brains GmbH<br>
>>><br>
>>> Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
>>> Phone : +49 89 189 47 41-16<br>
>>> Fax : +49 89 189 47 41-09<br>
>>> E-Mail : <a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a><br>
>>> PGP : Public key available on request.<br>
>>><br>
>>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
>><br>
>><br>
>><br>
>><br>
>> --<br>
>> Json Zhang<br>
>> Best Regards<br>
><br>
><br>
><br>
><br>
> --<br>
> Json Zhang<br>
> Best Regards<br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<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>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Json Zhang<div>Best Regards</div></div>
</div></div>