#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 _______________________________________________ bugs mailing list bugs@rtems.org http://lists.rtems.org/mailman/listinfo/bugs