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