Condition Variables for RTEMS
zhang json
json.a.zhang at gmail.com
Tue Mar 4 13:49:49 UTC 2014
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140304/35c55ceb/attachment-0001.html>
More information about the devel
mailing list