On 11/22/05, David Singleton <dsingleton@xxxxxxxxxx> wrote:I'd also like some advice on the direction POSIX is heading with
robust pthread_mutexes and priority inheritance.
Robust mutexes are not in POSIX nor have they been proposed for
inclusion in the next revision. If a sane semantics can be determined
I might submit it for inclusion.
As for priority inheritance, there is nothing to add, the feature is
rt-nptl supports 'robust' behavior, there will be two robust modes,
one is PTHREAD_MUTEX_ROBUST_NP mode, the other is
PTHREAD_MUTEX_ROBUST_SUN_NP mode. When the owner of a mutex dies in
the first mode, the waiter will set the mutex to ENOTRECOVERABLE
state, while in the second mode, the waiter needs to call
pthread_mutex_setconsistency_np to change the state manually.
Currently the PTHREAD_MUTEX_ROBUST_NP is providing
the fucntionality described by the PTHREAD_MUTEX_ROBUST_SUN_NP.
This description makes no sense. ENOTRECOVERABLE is the error code
used if, surprise, the data/mutex cannot be recovered. I.e., it is
*not* consistent. It is identical to calling pthread_mutex_unlock on
a mutex which was locked when pthread_mutex_lock returned EDEADOWNER.
All waiters are woken and subsequent locking attempts will fail in
this case with ENOTRECOVERABLE.
So, if PTHREAD_MUTEX_ROBUST_NP really causes ENOTRECOVERABLE to be
returned then this form is useless as it is trivially achieved with
the PTHREAD_MUTEX_ROBUST_SUN_NP form. Plus: not defining it means
less confusion since the semantics doesn't differ from Solaris (and
there would be a bigger change to get the change added to POSIX).
I cannot really comment much on the kernel side. For my taste the
robust futex functionality is impacting the far more commen code path
too much. I would like to see much of the added code moved completely
out of the fast path. Robust mutexes are slow, this won't make it
The userlevel part is completely unacceptable. It's broken and what
is there in code has the same problem as the kernel code: it punishes
code which does not require this new feature. I don't worry about
this part, though, since I would write this part myself in any case
once there is an agreed upon kernel part.
Having this said, I certainly would like to get the robust futex part
in. But not the priority handling part. The two are completely
independent in principal. I don't agree at all with the current
implementation of the priority inheritance.
So, if you split out the robust futex still, eliminate all the support
added for priority inheritance, you get my full support for adding the
code to mainline.