Hello Pavel,
On 04/06/16 11:57, Pavel Pisa wrote:
Hello Sebastian and others,
generally, I am highly thankfull for all that hard work done to bring
RTEMS to multicore SoC era and all that with attempt to keep RTEMS
API compatible with existing applications.
On Friday 03 of June 2016 15:26:15 Sebastian Huber wrote:
On 03/06/16 15:24, Joel Sherrill wrote:
Binary semaphores with no protocol can be used for condition
synchronization. This was described way back by Dijkstra. Usually the
binary semaphore starts locked, a thread will then block upon an
attempt to lock it. An ISO or other thread can release or flush to
announce the condition.
This is a simple binary semaphore in RTEMS (RTEMS_SIMPLE_BINARY_SEMAPHORE).
This patch is about binary semaphores (RTEMS_BINARY_SEMAPHORE).
But if the RTEMS API is getting touched then in this regard I rise
again my opinion that semaphores and mutexes should be strictly separated.
This would prevent confusion and help to static code analyze tools etc.
in general I agree.
The RTEMS_BINARY_SEMAPHORE has been near to mutex in the past but now
it is strictly a mutex (if I am correct). But when application programmer
ports, intend to use, binary semaphore, they have to know that binary
semaphore is RTEMS_SIMPLE_BINARY_SEMAPHORE in the RTEMS world.
Before proposed patches intuitive use has not been ideal but at least
does not lead to direct breakage.
One option is to left only single API (rtems_semaphore_*) and define
RTEMS_MUTEX_SEMAPHORE instead of RTEMS_BINARY_SEMAPHORE. But there is
problem left to catch incorrect assumptions what is mutex
and what semaphore in functions/subsystems files which do not directly
include corresponding semaphore initialization and its kind.
And confusion would not be prevented.
That is why I suggest to separate set of SCORE and corresponding
RTEMS directives for mutexes
rtems_mutex_*
However, I would rather consider the Classic API as frozen. We should
focus on proper support for standard APIs like C11, C++11 and POSIX threads.
In addition, for SMP the object identifier approach is useless for high
performance applications due to three reasons
1. the object identifier to object translation is an overhead,
2. you cannot control the object placement with respect to cache lines,
due to the object table you may observe false sharing, and
3. the 65535 objects limitation due to the 16 bit identifier is to small
for some applications (e.g. the one using the T4240).
Dynamic applications have a problem with the object create/delete, e.g.
OpenMP performance was really bad with using objects.
A core mutex with SMP support needs 16 bytes on a 32-bit machine. For
the plain object you need 20 bytes. So, the object administration data
exceeds the functional data in case of mutexes.
This helps to static code analysis and incorrect use cases catching
(for example by Coccinelle http://coccinelle.lip6.fr ).
There should be some wrapper which allows to use semaphores
directives as mutexes during code transition period/one or two
releases but new applications and mainline RTEMS code should
switch to use rtems_mutex_.
With the C11 threads API you are already able to use the clang Thread
Safety Annotations, see
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=newlib/libc/include/threads.h;h=9fb08b03d1eb20024c0d680a7924336ec7ea57bb;hb=HEAD
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=newlib/libc/include/sys/cdefs.h;h=2a55a92e9589c99055f2c0cc443d152fe5d04b46;hb=HEAD#l646
--
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.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
