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