<div dir="ltr">Hi Gedare,<div><br><div class="gmail_extra"><div class="gmail_quote">2014-03-17 9:59 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"> Hi Json,<br>
<br>
Please remove _CORE from the score interfaces. This _CORE is not part<br>
of the current Coding Conventions:<br>
<a href="http://www.rtems.org/wiki/index.php/Coding_Conventions#SuperCore" target="_blank">http://www.rtems.org/wiki/index.php/Coding_Conventions#SuperCore</a><br>
<br></blockquote><div>OK, i will follow it. Thank you!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For priority inversion, see<br>
<a href="http://ertl.jp/~shinpei/conf/ospert13/slides/TommasoCucinotta.pdf" target="_blank">http://ertl.jp/~shinpei/conf/ospert13/slides/TommasoCucinotta.pdf</a> and<br>
<a href="http://ertl.jp/~shinpei/conf/ospert13/OSPERT13_proceedings_web.pdf#page=46" target="_blank">http://ertl.jp/~shinpei/conf/ospert13/OSPERT13_proceedings_web.pdf#page=46</a><br>
to start.<br></blockquote><div>Great, very useful references.</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>
On Sun, Mar 16, 2014 at 8:42 PM, zhang json <<a href="mailto:json.a.zhang@gmail.com">json.a.zhang@gmail.com</a>> wrote:<br>
> Hi all,<br>
><br>
> I have updated my proposal on both melange[0] and github[1], if you have any<br>
> comment please tell me. Thank you!<br>
><br>
> Updates:<br>
> 1. Modify the plan scheduling according to Gedare comments, thank you<br>
> Gedare!<br>
> 2. Add a plan for 'Improve the classic CV capabilities, such as dealing with<br>
> priority inversion', this feature is mentioned on wiki[2], and i have a<br>
> basic understand about its meaning. But if anyone can explain more deeper i<br>
> will be grateful for you.<br>
><br>
> 0.<br>
> <a href="https://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2014/json1984/5629499534213120" target="_blank">https://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2014/json1984/5629499534213120</a><br>
> 1. <a href="https://github.com/cloud-hot/proposal/blob/master/proposal.md" target="_blank">https://github.com/cloud-hot/proposal/blob/master/proposal.md</a><br>
> 2. <a href="http://wiki.rtems.org/wiki/index.php/Condition_Variables" target="_blank">http://wiki.rtems.org/wiki/index.php/Condition_Variables</a><br>
><br>
> 2014-03-10 20:46 GMT+08:00 zhang json <<a href="mailto:json.a.zhang@gmail.com">json.a.zhang@gmail.com</a>>:<br>
><br>
>> Hi all,<br>
>><br>
>> I have updated my proposal, and your comments are welcome!<br>
>><br>
>> <a href="https://github.com/cloud-hot/proposal/blob/master/proposal.md" target="_blank">https://github.com/cloud-hot/proposal/blob/master/proposal.md</a><br>
>><br>
>><br>
>><br>
>> 2014-03-04 21:49 GMT+08:00 zhang json <<a href="mailto:json.a.zhang@gmail.com">json.a.zhang@gmail.com</a>>:<br>
>><br>
>>><br>
>>> 2014-03-04 21:32 GMT+08:00 Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>>:<br>
>>><br>
>>>> 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>><br>
>>>> wrote:<br>
>>>> > Dear all,<br>
>>>> ><br>
>>>> > Recently i have been study the RTEMS code and all related resource<br>
>>>> > about<br>
>>>> > condition variables. At the meantime i am preparing a proposal for<br>
>>>> > this GSOC<br>
>>>> > project. Although it is just a skeleton draft, i think it is better to<br>
>>>> > throw<br>
>>>> > it ASAP. So that everyone can give me some valuable suggestions. And<br>
>>>> > my<br>
>>>> > proposal is managed by github, so if you have any comments you can<br>
>>>> > 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>
>>>> Please add yourself and the link to your proposal to the table at<br>
>>>><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>
>>>><br>
>>> Done+<br>
>>><br>
>>>><br>
>>>> ><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>
>>>> >>>><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>
>>>> >>>><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.<br>
>>>> >>>> You<br>
>>>> >>>> can search<br>
>>>> >>>> for "condition variable" in a search engine to get<br>
>>>> >>>> some<br>
>>>> >>>> useful<br>
>>>> >>>> background material. More below.<br>
>>>> >>>><br>
>>>> >>>> Thank you for your reply. I will search and prepare this<br>
>>>> >>>> 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<br>
>>>> >>>> the<br>
>>>> >>>> GSOC2014, and from<br>
>>>> >>>> > 'Open Project' i found a interesting project<br>
>>>> >>>> 'Condition<br>
>>>> >>>> Variables'. So i<br>
>>>> >>>> > want to know the basic information about the status<br>
>>>> >>>> of<br>
>>>> >>>> this<br>
>>>> >>>> project.<br>
>>>> >>>> ><br>
>>>> >>>> > There is a bug [1] which is maybe related to it but<br>
>>>> >>>> it<br>
>>>> >>>> seems that<br>
>>>> >>>> > 'Condition Variables' is not the main problem of<br>
>>>> >>>> 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)<br>
>>>> >>>> implementation<br>
>>>> >>>> within the<br>
>>>> >>>> classic API located in cpukit/rtems/*, and also within<br>
>>>> >>>> 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<br>
>>>> >>>> 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<br>
>>>> >>>> only<br>
>>>> >>>> available for the PThread API. What we need is a definition<br>
>>>> >>>> for the<br>
>>>> >>>> Classic API and a shared implementation. We should also<br>
>>>> >>>> address<br>
>>>> >>>> potential<br>
>>>> >>>> priority inversion issues of CV in combination with priority<br>
>>>> >>>> based<br>
>>>> >>>> schedulers.<br>
>>>> >>>><br>
>>>> >>>> Could you tell me where i can find the code of CV implementation<br>
>>>> >>>> for the<br>
>>>> >>>> Pthread API? and CV is also implemented in the score? then needed<br>
>>>> >>>> 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<br>
>>>> >>>> the<br>
>>>> >>>> implementation?<br>
>>>> >>>> It should implement a classic API condition variable<br>
>>>> >>>> that<br>
>>>> >>>> can be<br>
>>>> >>>> similar to the classic API implementation of semaphore<br>
>>>> >>>> (cpukit/rtems/include/rtems/__rtems/sem.h and<br>
>>>> >>>> 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<br>
>>>> >>>> condvar<br>
>>>> >>>> and the<br>
>>>> >>>> classic API condition variables.<br>
>>>> >>>><br>
>>>> >>>> Yeah, i will refer to implementation of semaphore and<br>
>>>> >>>> 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<br>
>>>> >>>> of<br>
>>>> >>>> RTEMS is<br>
>>>> >>>> becoming better, some SMP synchronization primitives have<br>
>>>> >>>> been<br>
>>>> >>>> support,<br>
>>>> >>>> like<br>
>>>> >>>> atomic. I am wondering whether semaphore and mutex is<br>
>>>> >>>> supported<br>
>>>> >>>> SMP?<br>
>>>> >>>><br>
>>>> >>>><br>
>>>> >>>> The SMP support in RTEMS is currently based on a Giant lock.<br>
>>>> >>>> So<br>
>>>> >>>> most<br>
>>>> >>>> objects simply work.<br>
>>>> >>>><br>
>>>> >>>> And in the future should the Giant lock be removed? so now should<br>
>>>> >>>> we<br>
>>>> >>>> consider<br>
>>>> >>>> this situation, or we can first use Giant lock and then replace it<br>
>>>> >>>> with<br>
>>>> >>>> other<br>
>>>> >>>> safe lock later.<br>
>>>> >>><br>
>>>> >>><br>
>>>> >>> Yes, the Giant lock must be removed to get a real-time operating<br>
>>>> >>> system<br>
>>>> >>> that can compete on the market. Removing the Giant lock is however<br>
>>>> >>> 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<br>
>>>> >>> 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>
>>>> > _______________________________________________<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>
>>><br>
>>> --<br>
>>> Json Zhang<br>
>>> Best Regards<br>
>><br>
>><br>
>><br>
>><br>
>> --<br>
>> Json Zhang<br>
>> Best Regards<br>
><br>
><br>
><br>
><br>
> --<br>
> Json Zhang<br>
> Best Regards<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></div>