[PATCH] rtems: Fix no protocol mutex release

Sebastian Huber sebastian.huber at embedded-brains.de
Tue Jun 7 08:07:26 UTC 2016

On 07/06/16 09:48, Chris Johns wrote:
> On 07/06/2016 17:31, Sebastian Huber wrote:
>> 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 not sure about the term legacy component but I see what you are 
> saying. For new application user have a range of alternatives to 
> choose from and these are not fully proven or in a release. I am not 
> sure what sort of footprint they have as I have not seen any real data 
> so are they suitable for small memory devices?

The C++11 non-recursive mutex with full SMP support and priority 
inheritance (OMIP in the future) needs on a 32-bit machine 16 bytes 
(could be 12 bytes, if we use an MCS lock instead of the ticket lock). 
Initialization is a simple memset().

> The Classic API has a wide user base and there is a lot of code using 
> it and some has a long life cycle. I do not see the Classic API going 
> away in the near, medium or long term. If there is a way to improve 
> the existing Classic API via a separate mutex then we should consider 
> it. I think this is a good idea. It is cleaner and less likely to 
> cause the errors we are seeing.

I didn't ever mention to remove the Classic API. My point is that the 
Classic API has some inherent weaknesses by design that makes it 
unsuitable for use in high performance SMP systems and low end systems. 
It leads also to complex configuration issues for device driver 
resources that frequently pop up on the mailing list.

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