[PATCH] rtems: Fix no protocol mutex release

[Sebastian Huber]

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.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.