Condition Variables for RTEMS
Gedare Bloom
gedare at rtems.org
Tue Mar 4 13:32:55 UTC 2014
On Mon, Mar 3, 2014 at 7:51 PM, zhang json <json.a.zhang at gmail.com> wrote:
> 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
>
Please add yourself and the link to your proposal to the table at
http://wiki.rtems.org/wiki/index.php/RTEMSSummerOfCode#Students.27_Proposals
>
>
> 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
>
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel
>
More information about the devel
mailing list