@ page 1107-1126 line 34679-35213 section pthread_rwlock_* objection
Problem:
The Reader/Writer locks defined in POSIX.1j were intended for shared
memory multiprocessors, and they had no requirements for real-time
behavior. For this reason no priority inheritance or priority ceiling
mechanisms were specified for them, and thus applications using
Reader/Writer locks may suffer from unbounded priority inversions,
leading to delays that have a very low probability of ocurring, but
can be very long and this is almost certainly unacceptable for
real-time applications.
The situation changed when Reader/Writer locks were made mandatory
under the Threads option during the POSIX.1 revision. Because the
POSIX.13 realtime profiles require the Threads option, Reader/Writer
locks are also required now. We should fix these synchronization
primitives so that they can also be usable inside applications with
real-time requirements.
Mutexes have three possible synchronization protocols:
PTHREAD_PRIO_NONE: No priority inheritance; unbounded priority
inversions are possible, and thus this option is for non-realtime
PTHREAD_PRIO_INHERIT: Basic priority inheritance protocol. The
thread owning on one of these mutexes inherits the priorities of
other threads blocked on the mutex. This avoids unbounded priority
inversions. But on multiprocessors it is well known that there is
another source of unbounded priority inversion called "remote
blocking" [1][2], by which a thread in one processor may block
another thread in another processor for very long periods of time.
PTHREAD_PRIO_PROTECT: This is the immediate priority ceiling
protocol. The thread owning the mutex unconditionally inherits the
priority ceiling of the mutex. Using the appropriate values for
the ceilings, this protocol avoids both unbounded priority
inversions and remote blocking [1][2].
Reader/Writer locks are used in applications that may run in
multiprocessor systems (otherwise mutexes are equally useful). For
this reason, basic priority inheritance is not appropriate because in
multiprocessors we also need to address remote blocking. Consequently,
the standard should specify the priority ceiling protocol for
Reader/Writer locks, as an optional feature.
Remote blocking occurs with mutually exclusive synchronization in
multiprocessors. Suppose two threads (thread-A and thread-B) executing
in two processors (P1 and P2, respectively) and contending for the
same mutex. Suppose that thread A holds the mutex, and thread B is
blocked waiting for it. The desirable case is that the maximum delay
(also called blocking) experienced by thread B is the duration of the
critical section, i.e., the time thread A is holding the
mutex. Critical sections are usually designed to be very short, and
this mininizes blocking. However in this case thread-A could be
preempted by a higher priority thread-C executing in processor P1. In
that case thread-B has to wait for the whole duration of thread-C (and
perhaps for other threads also preempting, possibly multiple
times). Priority inheritance does not solve the problem; in our
example, thread-A would inherit the priority of thread-B, but thread-C
can have higher priority and thus cause the long delay. The blocking
time is no longer bounded by the duration of critical sections and
this problem is just as bad as traditional uniprocessor unbounded
priority inversion.
The solution to the problem of remote blocking is to set a priority
ceiling for the mutex that is high enough to prevent all undesired
preemption effects during the critical sections.
There is a lot of experience with Reader/Writer locks and the priority
ceiling in Ada, because Ada's protected objects have the same
multiple-readers-single-writer semantics as the POSIX Reader/Writer
locks.
The Solaris kernel has inversion-proof reader/writer locks.
References
[1] R. Rajkumar, L. Sha, and J.P. Lehoczky. "Real-Time Synchronization
Protocols for Multiprocessors". IEEE Real-Time Systems Symposium,
December 1988.
[2] R. Rajkumar. "Real-Time Synchronization Protocols for Shared
Memory Multiprocessors". Proceedings of the 10th International
Conference on Distributed Computing, 1990.
Action:
If the Thread Priority Protection option is supported, two additional
attributes should be added to Reader/Writer locks: protocol, and
prioceiling. Protocol should be able to have the values
PTHREAD_PRIO_NONE
or PTHREAD_PRIO_PROTECT (but not PTHREAD_PRIO_INHERIT). The semantics
of these two attributes should be the same as for mutexes.
The presence of these attributes implies two functions to set the
attributes, and another two functions to get them.
In addition, a function to dynamically set the priority ceiling and
another one to get it should be added, with the same semantics as for
the mutexes.
Note
The requested action may seem too important for a technical
corrigenda. In that case, the POSIX Realtime System Services Working
Group would like to take this action as a work item for a future
amendment to the standard.
|