<div dir="ltr">Hi Sebastian,<div><br></div><div>Thank you for your reply!</div><div><br><div class="gmail_extra"><div class="gmail_quote">2014-03-03 15:06 GMT+08:00 Sebastian Huber <span dir="ltr"><<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 2014-03-02 03:40, zhang json wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
<br>
2014-02-28 15:15 GMT+08:00 Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-<u></u>brains.de</a><br></div>
<mailto:<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@<u></u>embedded-brains.de</a>>>:<div class=""><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" target="_blank">gedare@rtems.org</a><br>
<mailto:<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>><br></div>
<mailto:<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a> <mailto:<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>>>>:<div class=""><br>
<br>
<br>
You may like to read<br></div>
<a href="http://wiki.rtems.org/wiki/__index.php/SMP#Non-Preempt___Mode_for_Mutual_Exclusion" target="_blank">http://wiki.rtems.org/wiki/__<u></u>index.php/SMP#Non-Preempt___<u></u>Mode_for_Mutual_Exclusion</a><div class="">
<br>
<<a href="http://wiki.rtems.org/wiki/index.php/SMP#Non-Preempt_Mode_for_Mutual_Exclusion" target="_blank">http://wiki.rtems.org/wiki/<u></u>index.php/SMP#Non-Preempt_<u></u>Mode_for_Mutual_Exclusion</a>><br>
in addition to the Condition Variables project page. You can search<br>
for "condition variable" in a search engine to get some useful<br>
background material. More below.<br>
<br>
Thank you for your reply. I will search and prepare this project 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" target="_blank">json.a.zhang@gmail.com</a> <mailto:<a href="mailto:json.a.zhang@gmail.com" target="_blank">json.a.zhang@gmail.com</a><u></u>><br></div>
<mailto:<a href="mailto:json.a.zhang@gmail.com" target="_blank">json.a.zhang@gmail.com</a> <mailto:<a href="mailto:json.a.zhang@gmail.com" target="_blank">json.a.zhang@gmail.com</a><u></u>>__>><div class="">
<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 this<br>
project.<br>
><br>
> There is a bug [1] which is maybe related to it but it seems that<br>
> 'Condition Variables' is not the main problem of this bug. So<br>
my confusion<br>
> is blow:<br>
><br>
> 1. As one of the classic operating system synchronization<br>
primitives whether<br>
> RTEMS has a basic 'Condition Variables' support?<br>
RTEMS lacks a condition variable (monitor) implementation within the<br>
classic API located in cpukit/rtems/*, and also within the supercore<br>
"kernel" interface located in cpukit/score/*. There is condition<br>
variables support in posix, as the<br></div>
cpukit/posix/include/rtems/__<u></u>posix/condimpl.h.<div class=""><br>
<br>
OK, i have some rtems experience so i will first design the CV 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 potential<br>
priority inversion issues of CV in combination with priority based 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 is to<br>
implement a classic API for CV and shared its implementation?<br>
</div></blockquote>
<br>
Answering this question gives you a good opportunity to discover the RTEMS sources.<br>
<br></blockquote><div>Yeah, recently i have been studying the RTEMS code.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
<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 can be<br>
similar to the classic API implementation of semaphore<br></div>
(cpukit/rtems/include/rtems/__<u></u>rtems/sem.h and semimpl.h). The<div class=""><br>
condition<br>
variable should be implemented in the supercore (cpukit/score) and<br>
that implementation should be shared by the posix condvar and the<br>
classic API condition variables.<br>
<br>
Yeah, i will refer to implementation of semaphore and mutex. And there<br>
are lots<br>
of open source CV implementation for many os, such freebsd, netbsd, linux,<br>
eCos. About linux its license may be is not compatible with 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 RTEMS is<br>
becoming better, some SMP synchronization primitives have been support,<br>
like<br>
atomic. I am wondering whether semaphore and mutex is supported SMP?<br>
<br>
<br>
The SMP support in RTEMS is currently based on a Giant lock. So most<br>
objects simply work.<br>
<br>
And in the future should the Giant lock be removed? so now should we consider<br>
this situation, or we can first use Giant lock and then replace it with other<br>
safe lock later.<br>
</div></blockquote>
<br>
Yes, the Giant lock must be removed to get a real-time operating system that can compete on the market. Removing the Giant lock is however a major 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/<u></u>index.php?title=SMP#Fine_<u></u>Grained_Locking</a><div class="HOEnZb"><div class="h5"><br></div>
</div></blockquote><div>Maybe i can consider it as a future work after GSOC project.</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>
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" target="_blank">sebastian.huber@embedded-<u></u>brains.de</a><br>
PGP : Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<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>