Condition Variables for RTEMS

zhang json json.a.zhang at gmail.com
Mon Mar 17 00:42:08 UTC 2014


Hi all,

I have updated my proposal on both melange[0] and github[1], if you have
any comment please tell me. Thank you!

Updates:
1. Modify the plan scheduling according to Gedare comments, thank you
Gedare!
2. Add a plan for 'Improve the classic CV capabilities, such as dealing
with priority inversion', this feature is mentioned on wiki[2], and i have
a basic understand about its meaning. But if anyone can explain more deeper
i will be grateful for you.

0.
https://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2014/json1984/5629499534213120
1. https://github.com/cloud-hot/proposal/blob/master/proposal.md
2. http://wiki.rtems.org/wiki/index.php/Condition_Variables

2014-03-10 20:46 GMT+08:00 zhang json <json.a.zhang at gmail.com>:

> Hi all,
>
> I have updated my proposal, and your comments are welcome!
>
> https://github.com/cloud-hot/proposal/blob/master/proposal.md
>
>
>
> 2014-03-04 21:49 GMT+08:00 zhang json <json.a.zhang at gmail.com>:
>
>
>> 2014-03-04 21:32 GMT+08:00 Gedare Bloom <gedare at rtems.org>:
>>
>> 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
>>>
>>> Done+
>>
>>
>>> >
>>> >
>>> > 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
>>> >
>>>
>>
>>
>>
>> --
>> Json Zhang
>> Best Regards
>>
>
>
>
> --
> Json Zhang
> Best Regards
>



-- 
Json Zhang
Best Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140317/c67d356b/attachment-0001.html>


More information about the devel mailing list