Hi Gedare, 2014-03-17 9:59 GMT+08:00 Gedare Bloom <ged...@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.zh...@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.zh...@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.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 > > > > > > > > > > -- > > Json Zhang > > Best Regards > -- Json Zhang Best Regards
_______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
