On 2014-03-02 03:40, zhang json wrote:
2014-02-28 15:15 GMT+08:00 Sebastian Huber <[email protected]
<mailto:[email protected]>>:
On 2014-02-28 01:12, zhang json wrote:
2014-02-26 1:07 GMT+08:00 Gedare Bloom <[email protected]
<mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>:
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
<[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>__>>
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.
> 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
--
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 : [email protected]
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
rtems-devel mailing list
[email protected]
http://www.rtems.org/mailman/listinfo/rtems-devel
