[RTEMS Project] #2843: Use self-contained objects instead of Classic API for drivers and support libraries (was: Use C11 mutexes instead of Classic API priority inheritance semaphores)

[RTEMS trac]

#2843: Use self-contained objects instead of Classic API for drivers and support
libraries
-----------------------------+------------------------------
 Reporter:  sebastian.huber  |       Owner:  sebastian.huber
     Type:  enhancement      |      Status:  new
 Priority:  normal           |   Milestone:  4.12
Component:  cpukit           |     Version:  4.12
 Severity:  normal           |  Resolution:
 Keywords:                   |
-----------------------------+------------------------------
Description changed by sebastian.huber:

Old description:

> Use C11 mutexes instead of Classic API priority inheritance semaphores
> throughout the RTEMS code base as a performance optimization and to
> simplify the application configuration.
>
> See discussion:
>
> https://lists.rtems.org/pipermail/devel/2016-December/016543.html

New description:

 The Classic API has some weaknesses:

 * Dynamic memory (the workspace) is used to allocate object pools.  This
 requires a complex configuration with heavy use of the C pre-processor.
 * Objects are created via function calls which return an object
 identifier. The object operations use this identifier and map it
 internally to an object representation.
 * The objects reside in a table, e.g. they are suspect to false sharing of
 cache lines.
 * The object operations use a rich set of options and attributes.  For
 each object operation these parameters must be evaluated and validated at
 run-time to figure out what to do exactly for this operation.

 The overhead for Classic API mutexes used for example in Termios and the
 SPI framework is significant, see discussion:

 https://lists.rtems.org/pipermail/devel/2016-December/016543.html

 There are some API options available:

 1. Use C11 mutexes and condition variables.
 2. Turn the POSIX synchronization objects into self-contained objects and
 use them.
 3. Use FreeBSD synchronization objects like
 [https://www.freebsd.org/cgi/man.cgi?query=mutex&sektion=9 MUTEX(9)] or
 [https://www.freebsd.org/cgi/man.cgi?query=condvar&apropos=0&sektion=9&manpath=FreeBSD+10.3-RELEASE+and+Ports&arch=default&format=html
 CONDVAR(9)].
 4. Add RTEMS-specific self-contained synchronization objects and use them.

 Option 1. and 2. lack support for binary semaphores which are used for
 task/interrupt synchronization, e.g. Termios.

 Option 2. needs run-time evaluation to figure out the actual object
 variant, e.g. non-recursive, recursive, ceiling, error-checking, robust
 POSIX mutex.

 Option 3. uses hash tables, thus it is not suitable for real-time systems.

 Option 1. and 2. lack support for user-defined object names that may help
 for system diagnostic, tracing and debugging.

 Option 4. could be used to avoid all shortcomings of options 1-3. It would
 be trivial to implement, test and document.

 In order to enable user-defined object names one option is to add a const
 char *name member to Thread_queue_Queue.

--

--
Ticket URL: <http://devel.rtems.org/ticket/2843#comment:1>
RTEMS Project <http://www.rtems.org/>
RTEMS Project