Condition Variables for RTEMS
zhang json
json.a.zhang at gmail.com
Tue Mar 4 00:51:55 UTC 2014
Dear all,
Recently i have been study the RTEMS code and all related resource about
condition variables. At the meantime i am preparing a proposal for this
GSOC project. Although it is just a skeleton draft, i think it is better to
throw it ASAP. So that everyone can give me some valuable suggestions. And
my proposal is managed by github, so if you have any comments you can just
open a new issue to me. Waiting for all your comments! Thank you!
https://github.com/cloud-hot/proposal
2014-03-04 8:42 GMT+08:00 zhang json <json.a.zhang at gmail.com>:
> 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
>
--
Json Zhang
Best Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140304/203e1265/attachment-0001.html>
More information about the devel
mailing list