[PATCH] rtems: Fix no protocol mutex release

[Sebastian Huber]

On 06/06/16 14:05, Pavel Pisa wrote:
> Hello Sebastian,
>
> On Monday 06 of June 2016 13:12:52 Sebastian Huber wrote:
> ....
>>> 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.
>>
> ...
>>> 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
> I see two possible problems when actual state is unchanged
>
> 1) it would be unfortunate if the need to keep mutexes and semaphores
>     under rtems_semaphore would block to clean stuff and separate
>     these in SCORE level.

No, the Score level is fine now. Here mutexes and semaphores are 
separated. In addition I entangled the different mutex variants and 
moved the variant selection to the API levels. This allows more 
efficient use if only a particular variant is of interest, e.g. in case 
of internal mutexes (rework not yet done).

>
> 2) classic RTEMS API is used together with BSP API variants in BSPs
>     and drivers code. It has been (seems like) preferred API for these
>     areas because POSIX API has been optional and sometimes POSIX
>     is more verbose/complex (for example building prio. inherit mutexes
>     take quite more lines - preparing attributes etc.). So some simpler
>     primitives would be better for these areas
>       - it can be wrapper to pthread_mutex_ with appropriate parameters
>       - it can be based directly on supercore
>       - should not be directly C++ synchronization, C++ support should
>         be optional
>     So if the RTEMS classic API is not cleaned in mutexes respect, then there
>     should be some guideline which API subset should be used in BSPs,
>     drivers and RTEMS subsystems. Option is to use BSD directives if BSD
>     compatibility layer would be included in main RTEMS repo.
>     But even that is not ideal solution.
>
>     If classic RTEMS API is not suggested for BSPs anymore then it would
>     worth to convert all mainline included code to selected preferred solution.
>
>  From my point of view, classic RTEMS API is reasonable for internal
> subsystems implementation. Then keeping it in shape and friendly for
> automatic static code analysis is important.
>
> So my proposal is to define rtems_mutex_ at least as direct alias
> to RTEMS binary semaphore with right flags preset forces, but flags
> left there for future tuning.
>
> The next step is to implement rtems_mutex right way and teach original
> rtems_semaphore to point to the right background primitive if it is
> initialized with RTEMS_BINARY_SEMAPHORE.
>
> I understand that it all is big amount of work and I cannot help
> much. But it would worth to discus and find some consensus what
> is a preferred direction.

Yes, its definitely worth to discuss this. My preferred solution would 
be to go away from the objects and treat the Classic objects as a legacy 
component. I am currently busy with the SMP implementation, so for me 
this is a long term topic. It is quite labour intensive to change the 
status quo, so we should be clear about a future direction before we 
start with its realization.

-- 
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.