Condition Variables for RTEMS

Tue Mar 4 00:42:24 UTC 2014

Hi Sebastian,

Thank you for your reply!

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

> On 2014-03-02 03:40, zhang json wrote:
>
>>
>> 2014-02-28 15:15 GMT+08:00 Sebastian Huber <sebastian.huber at embedded-
>> brains.de
>> <mailto: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>
>>         <mailto: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
>>
>>         <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>
>>              <mailto: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?
>>
>
> Answering this question gives you a good opportunity to discover the RTEMS
> sources.
>
> Yeah, recently i have been studying the RTEMS code.

>
>>               > 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.
>>
>
> 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.
>
> http://www.rtems.org/wiki/index.php?title=SMP#Fine_Grained_Locking
>
> Maybe i can consider it as a future work after GSOC project.

>
> --
> 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.
>

-- 
Json Zhang
Best Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140304/2a9aad16/attachment-0001.html>