On 11/22/05, David Singleton <[EMAIL PROTECTED]> 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 the priority inheritance. So, if you split out the robust futex still, eliminate all the supportadded for priority inheritance, you get my full support for adding thecode to mainline.
_______________________________________________ robustmutexes mailing list [email protected] https://lists.osdl.org/mailman/listinfo/robustmutexes
