Condition Variables for RTEMS
zhang json
json.a.zhang at gmail.com
Mon Mar 10 12:46:48 UTC 2014
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140310/c286f333/attachment-0001.html>
More information about the devel
mailing list