C11 Re: [PATCH 3/6] termios: Use C11 mutex for input/output

Chris Johns chrisj at rtems.org
Wed Dec 14 21:15:34 UTC 2016

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?


More information about the devel mailing list