2014-03-04 21:32 GMT+08:00 Gedare Bloom <ged...@rtems.org>: > On Mon, Mar 3, 2014 at 7:51 PM, zhang json <json.a.zh...@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.zh...@gmail.com>: > > > >> Hi Sebastian, > >> > >> Thank you for your reply! > >> > >> 2014-03-03 15:06 GMT+08:00 Sebastian Huber > >> <sebastian.hu...@embedded-brains.de>: > >> > >>> On 2014-03-02 03:40, zhang json wrote: > >>>> > >>>> > >>>> 2014-02-28 15:15 GMT+08:00 Sebastian Huber > >>>> <sebastian.hu...@embedded-brains.de > >>>> <mailto:sebastian.hu...@embedded-brains.de>>: > >>>> > >>>> > >>>> On 2014-02-28 01:12, zhang json wrote: > >>>> > >>>> > >>>> 2014-02-26 1:07 GMT+08:00 Gedare Bloom <ged...@rtems.org > >>>> <mailto:ged...@rtems.org> > >>>> <mailto:ged...@rtems.org <mailto:ged...@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.zh...@gmail.com <mailto:json.a.zh...@gmail.com> > >>>> <mailto:json.a.zh...@gmail.com > >>>> <mailto:json.a.zh...@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.hu...@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@rtems.org > > http://www.rtems.org/mailman/listinfo/rtems-devel > > > -- Json Zhang Best Regards
_______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
