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.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
