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