Condition Variables for RTEMS

[Sebastian Huber]

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.

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

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