Condition Variables for RTEMS

[Sebastian Huber]

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.

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

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