Condition Variables for RTEMS
Gedare Bloom
gedare at rtems.org
Mon Mar 17 01:59:56 UTC 2014
Hi Json,
Please remove _CORE from the score interfaces. This _CORE is not part
of the current Coding Conventions:
http://www.rtems.org/wiki/index.php/Coding_Conventions#SuperCore
For priority inversion, see
http://ertl.jp/~shinpei/conf/ospert13/slides/TommasoCucinotta.pdf and
http://ertl.jp/~shinpei/conf/ospert13/OSPERT13_proceedings_web.pdf#page=46
to start.
On Sun, Mar 16, 2014 at 8:42 PM, zhang json <json.a.zhang at gmail.com> wrote:
> 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
More information about the devel
mailing list