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
> > > 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 > _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
