Hello,
I checked in a patch set today that reworks the thread priority
management. This improves the priority inheritance protocol for example.
https://git.rtems.org/rtems/commit/?id=300f6a481aaf9e6d29811faca71bf7104a01492c
Previously, each thread used a resource count that reflects the count of
mutexes owned by the thread. A thread could temporarily get a higher
priority via priority inheritance due to mutexes which it owned
directly. However, it did keep this temporary high priority until it
released its last mutex (resource count changes from 1 to 0). So, in
case of nested mutexes, it could have a high priority even though it
already released the corresponding mutex.
Lets consider this scenario. We have a file system instance protected by
one mutex (e.g. JFFS2) and a dynamic memory allocator protected by
another mutex. A low priority thread performs writes some log data into
a file, thus it acquires the file system instance mutex. The file system
allocates dynamic memory. Now a high priority thread interrupts and
tries to allocate dynamic memory. The allocator mutex is already owned,
so the priority of the low priority thread is raised to the priority of
the high priority thread. The memory allocation completes and the
allocator mutex is released, since the low priority thread still owns
the file system instance mutex it continues to execute with the high
priority (the high priority thread is not scheduled). It may now perform
complex and long file system operations (e.g. garbage collection, polled
flash erase and write functions) with a high priority.
In the new implementation the thread priorities are tracked accurately
and priority changes take place immediately, e.g. priority changes are
not deferred until the thread releases its last resource. The actual
priority of a thread is now an aggregation of priority nodes. The thread
priority aggregation for the home scheduler instance of a thread
consists of at least one priority node, which is normally the real
priority of the thread. The locking protocols (e.g. priority ceiling
and priority inheritance), rate-monotonic period objects and the POSIX
sporadic server add, change and remove priority nodes.
Priority inheritance works now recursively, e.g. a thread T0 owns mutex
A, a thread T1 owns mutex B and waits for mutex A, a thread T2 which
wants to obtain mutex B inherits its priority to the direct owner thread
T1 and the indirect owner thread T0.
In addition timeouts are supported (nothing new, however, this is quite
complex on SMP configurations) and we have a deadlock detection.
All these features are not for free. The additional storage space is
negligible and affects only the thread control block and the thread
stack. A non-recursive mutex object with support for priority
inheritance consists of an SMP spin lock and two pointers (e.g. 12 bytes
on a 32-bit machine in case of MCS spin locks). The implementation of
the common case of a mutex obtain/release with no previous owner/waiting
thread is next to optimal. The run-time of mutex obtain/release
operations depends now on the mutex dependency graph, which is defined
by the application. Complex and deeply nested mutex dependencies lead to
long mutex obtain/release sequences. However, also without the accurate
priority tacking in the scenario of complex dependencies, the overall
run-time behaviour is pretty bad due to production of parasitic high
priority threads or incomplete priority inheritance. Complex
dependencies are a problem itself and it is the duty of an application
designer to avoid them.
--
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
