Re: Robust Futex patches available
Ulrich Drepper <drepper <at> gmail.com>
2005-11-23 01:40:39 GMT
On 11/22/05, David Singleton <dsingleton <at> mvista.com> wrote:> I'd also like some advice on the direction
POSIX is heading with> respect to> robust pthread_mutexes and priority inheritance.
Robust mutexes are not in POSIX nor have they been proposed forinclusion in the next revision. If a sane
semantics can be determinedI might submit it for inclusion.
As for priority inheritance, there is nothing to add, the feature isfully described.
> 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 codeused if, surprise, the data/mutex
cannot be recovered. I.e., it is*not* consistent. It is identical to calling pthread_mutex_unlock ona
mutex which was locked when pthread_mutex_lock returned EDEADOWNER. All waiters are woken and
subsequent locking attempts will fail inthis case with ENOTRECOVERABLE.
So, if PTHREAD_MUTEX_ROBUST_NP really causes ENOTRECOVERABLE to bereturned then this form is useless as
it is trivially achieved withthe PTHREAD_MUTEX_ROBUST_SUN_NP form. Plus: not defining it meansless
confusion since the semantics doesn't differ from Solaris (andthere would be a bigger change to get the
change added to POSIX).
I cannot really comment much on the kernel side. For my taste therobust futex functionality is impacting
the far more commen code pathtoo much. I would like to see much of the added code moved completelyout of the
fast path. Robust mutexes are slow, this won't make itworse.
The userlevel part is completely unacceptable. It's broken and whatis there in code has the same problem as
the kernel code: it punishescode which does not require this new feature. I don't worry aboutthis part,
though, since I would write this part myself in any caseonce there is an agreed upon kernel part.
Having this said, I certainly would like to get the robust futex partin. But not the priority handling part.
The two are completelyindependent in principal. I don't agree at all with the currentimplementation of