[PATCH] rtems: Fix no protocol mutex release
Sebastian Huber
sebastian.huber at embedded-brains.de
Tue Jun 7 07:31:48 UTC 2016
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.
More information about the devel
mailing list