Condition Variables for RTEMS

[zhang json]

Hi Sebastian,

2014-02-28 15:15 GMT+08:00 Sebastian Huber <
sebastian.huber at embedded-brains.de>:

> On 2014-02-28 01:12, zhang json wrote:
>
>>
>> 2014-02-26 1:07 GMT+08:00 Gedare Bloom <gedare at rtems.org
>> <mailto:gedare at rtems.org>>:
>>
>>
>>     You may like to read
>>     http://wiki.rtems.org/wiki/index.php/SMP#Non-Preempt_
>> Mode_for_Mutual_Exclusion
>>     in addition to the Condition Variables project page. You can search
>>     for "condition variable" in a search engine to get some useful
>>     background material. More below.
>>
>> Thank you for your reply. I will search and prepare this project and a
>> draft
>> will be post ASAP.
>>
>>     On Tue, Feb 25, 2014 at 9:45 AM, zhang json <json.a.zhang at gmail.com
>>     <mailto:json.a.zhang at gmail.com>> wrote:
>>      > Hi all,
>>      >
>>      > I am a student who is preparing for participating  the GSOC2014,
>> and from
>>      > 'Open Project' i found a interesting project 'Condition
>> Variables'. So i
>>      > want to know the basic information about the status of this
>> project.
>>      >
>>      > There is a bug [1] which is maybe related to it but it seems that
>>      > 'Condition Variables' is not the main problem of this bug. So my
>> confusion
>>      > is blow:
>>      >
>>      > 1. As one of the classic operating system synchronization
>> primitives whether
>>      > RTEMS has a basic 'Condition Variables' support?
>>     RTEMS lacks a condition variable (monitor) implementation within the
>>     classic API located in cpukit/rtems/*, and also within the supercore
>>     "kernel" interface located in cpukit/score/*. There is condition
>>     variables support in posix, as the
>>     cpukit/posix/include/rtems/posix/condimpl.h.
>>
>> OK, i have some rtems experience so i will first design the CV and
>> implement it
>> in score component, then warp it into classic api.
>>
>
> We already have a CV implementation in RTEMS.  It is currently only
> available for the PThread API.  What we need is a definition for the
> Classic API and a shared implementation.  We should also address potential
> priority inversion issues of CV in combination with priority based
> schedulers.
>
> Could you tell me where i can find the code of CV implementation for the
Pthread API? and CV is also implemented in the score? then needed work is
to implement a classic API for CV and shared its implementation?

>
>
>>      > 2. If answer not from 1, what is the requirement of the
>> implementation?
>>     It should implement a classic API condition variable that can be
>>     similar to the classic API implementation of semaphore
>>     (cpukit/rtems/include/rtems/rtems/sem.h and semimpl.h). The condition
>>     variable should be implemented in the supercore (cpukit/score) and
>>     that implementation should be shared by the posix condvar and the
>>     classic API condition variables.
>>
>> Yeah, i will refer to implementation of semaphore and mutex. And there
>> are lots
>> of open source CV implementation for many os, such freebsd, netbsd, linux,
>> eCos. About linux its license may be is not compatible with RTEMS, so i
>> just
>> learn its idea instead of code.
>>
>>      > 3. Whether its implementation should support SMP?
>>      >
>>     The implementation must support SMP.
>>
>> Yeah, it will be a challenge. But as i know the SMP support of RTEMS is
>> becoming better, some SMP synchronization primitives have been support,
>> like
>> atomic. I am wondering whether semaphore and mutex is supported SMP?
>>
>
> The SMP support in RTEMS is currently based on a Giant lock.  So most
> objects simply work.
>
> And in the future should the Giant lock be removed? so now should we
consider this situation, or we can first use Giant lock and then replace it
with other safe lock later.

> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax     : +49 89 189 47 41-09
> E-Mail  : sebastian.huber at embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel
>



-- 
Json Zhang
Best Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140302/9171dcd1/attachment.html>