robust futex patch update

         Ingo,
                 here is an update for the robust futex patch. This
         patch adds support for robust and priority inheriting pthread
         mutexes malloc'd on the heap.  The orignal patch did not
         support malloc'd pthread_mutexes.

                 I also got rid of the duplicate get_robust_futex_key
         routine and unified it into the existing get_futex_key routine.

		I've changed Inaky's ownership_change_latency.c  test to include
	a call to set priority inheritance attribute on the pthread_mutexes
	and have run up to 400 waiters on a mutex.  I'm going to run the 7500
	waiters version over the weekend.

                 I'm planning on implementing a red/black tree for
         the heap as a linked list won't scale very well with lots
         of mutex lookups.  I'll keep you posted when I have it
         working.

thanks

Dave

         Ingo,
                 here is an update for the robust futex patch. This

Robust Futex patches available

    There are two new patches for Robust Futex support available at

    http://source.mvista.com/~dsingleton

    patch-2.6.14-rt13-rf3 fixes two locking bugs which caused hangs and 
deadlocks.

    patch-2.6.14-rt13-rf4 adds support for pthread_mutexes 'malloc'ed on 
the heap.

    I'd also like some advice on the direction POSIX is heading with 
respect to
    robust pthread_mutexes and priority inheritance.

    It appears there are some not used openposix tests that use 
different flags for
    defining robustness.      Here is a snip from the openposix robust 
test's README:

Robust Mutex Tests
------------------------
The tests are under <rtnptl-tests>/robust_test directory.

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.

Re: Robust Futex patches available

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

Re: Robust Futex patches available

On Nov 22, 2005, at 5:40 PM, Ulrich Drepper wrote:

> 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 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
> fully 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 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.

robust futex heap support patch

There is a new patch, patch-2.6.14-rt15-rf1,  that adds support for 
robust and priority inheriting
pthread_mutexes on the 'heap'.

The previous patches only supported either file based pthread_mutexes 
or mmapped anonymous memory based pthread_mutexes.  This patch allows 
pthread_mutexes
to be 'malloc'ed while using the PTHREAD_MUTEX_ROBUST_NP attribute
or PTHREAD_PRIO_INHERIT attribute.

The patch can be found at:

http://source.mvista.com/~dsingleton

David

There is a new patch, patch-2.6.14-rt15-rf1,  that adds support for 
robust and priority inheriting
pthread_mutexes on the 'heap'.

The previous patches only supported either file based pthread_mutexes 
or mmapped anonymous memory based pthread_mutexes.  This patch allows 
pthread_mutexes
to be 'malloc'ed while using the PTHREAD_MUTEX_ROBUST_NP attribute
or PTHREAD_PRIO_INHERIT attribute.

The patch can be found at:

Re: robust futex heap support patch

* david singleton <dsingleton <at> mvista.com> wrote:

> There is a new patch, patch-2.6.14-rt15-rf1, that adds support for 
> robust and priority inheriting pthread_mutexes on the 'heap'.

we need to go a bit slower. For now i had to remove robust-futexes from 
the -rt17 release because they broke normal (non-robust) futex support 
in -rt15. A simple mozilla startup would hang... Please send fixes 
against -rt16 and i'll try to re-add the robust futexes patch later on.  
You can find -rt16 at:

 http://people.redhat.com/mingo/realtime-preempt/older/patch-2.6.14-rt16

> The previous patches only supported either file based pthread_mutexes 
> or mmapped anonymous memory based pthread_mutexes.  This patch allows 
> pthread_mutexes to be 'malloc'ed while using the 
> PTHREAD_MUTEX_ROBUST_NP attribute or PTHREAD_PRIO_INHERIT attribute.
> 
> The patch can be found at:
> 
> http://source.mvista.com/~dsingleton

this patch looks much cleaner than the earlier one, but there's one more 
step to go: now that we've got the futex_head in every vma, why not hang 
all robust futexes to the vma, and thus get rid of ->robust_list and 
->robust_sem from struct address_space?

	Ingo

Re: robust futex heap support patch

On Nov 26, 2005, at 5:31 AM, Ingo Molnar wrote:

>
> * david singleton <dsingleton <at> mvista.com> wrote:
>
>> There is a new patch, patch-2.6.14-rt15-rf1, that adds support for
>> robust and priority inheriting pthread_mutexes on the 'heap'.
>
> we need to go a bit slower. For now i had to remove robust-futexes from
> the -rt17 release because they broke normal (non-robust) futex support
> in -rt15. A simple mozilla startup would hang... Please send fixes
> against -rt16 and i'll try to re-add the robust futexes patch later on.
> You can find -rt16 at:

whoops, sorry.

Here's he piece that broke regular futexes.  Futex wake doesn't
need to check to see if the robust list is null or not.

Index: linux-2.6.14/kernel/futex.c
===================================================================
--- linux-2.6.14.orig/kernel/futex.c
+++ linux-2.6.14/kernel/futex.c
 <at>  <at>  -323,10 +323,6  <at>  <at>  static int futex_wake(unsigned long uadd
         ret = get_futex_key(uaddr, &key, &head, &sem);
         if (unlikely(ret != 0))
                 goto out;
-       if (head == NULL) {
-               ret = -EINVAL;