Condition Variables for RTEMS
json.a.zhang at gmail.com
Tue Mar 4 00:42:24 UTC 2014
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-
>> <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
>> in addition to the Condition Variables project page. You can
>> for "condition variable" in a search engine to get some
>> background material. More below.
>> Thank you for your reply. I will search and prepare this project
>> and a
>> 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>__>>
>> > 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
>> > There is a bug  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
>> "kernel" interface located in cpukit/score/*. There is
>> variables support in posix, as the
>> 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
>> priority inversion issues of CV in combination with priority based
>> 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
>> implement a classic API for CV and shared its implementation?
> Answering this question gives you a good opportunity to discover the RTEMS
> Yeah, recently i have been studying the RTEMS code.
>> > 2. If answer not from 1, what is the requirement of the
>> 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).
>> 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
>> 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
>> 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
>> atomic. I am wondering whether semaphore and mutex is supported
>> 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
>> this situation, or we can first use Giant lock and then replace it with
>> 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.
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the devel