[PATCH] rtems: Fix no protocol mutex release

[Pavel Pisa]

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.

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.

Best wishes,


                Pavel Pisa