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