On 15/12/2016 00:39, Sebastian Huber wrote:
Use C11 mutexes instead of Classic semaphores as a performance
optimization and to simplify the application configuration.
The use of C11 mutexes has not been agreed too and we need to discuss
this in more detail before we allow use within RTEMS. I would like to
see positive agreement from all core maintainers before this and similar
patches can be merged.
RTEMS has required the use of the Classic API because:
1. Available on all architectures, BSPs and tool sets.
2. Always present in a build.
3. Was considered faster than POSIX.
The Classic API provides a base level of required functionality because
it is always available in supported tool sets and leads to the smallest
footprint because we do not need to link in more than one API.
I understand things change and move on so it is great to see this change
being proposed and our existing base line being challenged.
I see from your performance figures C11 mutexes are better and the
resources are allocated as needed and used which is a better model than
the Classic API's configuration table. This is nice.
Do all architectures and BSPs have working C11 support?
Is there tests in the RTEMS testsuite for C11 threading services?
What target resources are used to support this API, ie code and RAM usage?
Would the "tiny" footprint be smaller if all internal services including
compiler thread support are made C11? Could this actually be done? Parts
of POSIX has been creeping in over time so the position is a little
confused at the moment. I am not sure about a bits and pieces approach,
maybe a full switch is made.
Does C11 work on LLVM (I hear support is close)?
Where is the C11 API implemented? Is the threading code outside the
RTEMS source tree and what effect does that have on those looking to
certify RTEMS?
Does a change like this require a coding standard update?
Chris
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
