Condition Variables for RTEMS
zhang json
json.a.zhang at gmail.com
Mon Mar 17 23:59:39 UTC 2014
Hi Gedare,
2014-03-17 9:59 GMT+08:00 Gedare Bloom <gedare at rtems.org>:
> 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
>
> OK, i will follow it. Thank you!
> 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.
>
Great, very useful references.
>
> 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
>
--
Json Zhang
Best Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140318/8edcf413/attachment.html>
More information about the devel
mailing list