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