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.zh...@gmail.com>: > > 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 > -- Json Zhang Best Regards
_______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
