[PATCH v2][BZ #14417] Unlock mutex before going back to waiting for PI mutexes

[Jeff Law]

On 10/03/2012 04:31 AM, Siddhesh Poyarekar wrote:
> Hi,
>
> Here's the patch with comments updated as per Torvald's suggestion.
> For context on the patch, please see the following discussion:
>
> http://sourceware.org/ml/libc-alpha/2012-09/msg00557.html
>
> I held back on the abort code for now following Jeff's comment.  Does
> this look OK?
>
> Regards,
> Siddhesh
>
> nptl/ChangeLog:
>
> 	* Makefile (tests): New test case tst-cond24.
> 	(LDFLAGS-tst-cond24): Link tst-cond24 against librt.
> 	* sysdeps/unix/sysv/linux/i386/i486/pthread_cond_timedwait.S
> 	(__pthread_cond_timedwait): Unlock mutex before going back to
> 	wait in PI case.
> 	* sysdeps/unix/sysv/linux/i386/i486/pthread_cond_wait.S
> 	(__pthread_cond_wait): Likewise.  Revert handling of EAGAIN
> 	return from futex_wait.
> 	* sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S
> 	(__pthread_cond_timedwait): Unlock mutex before going back to
> 	wait in PI case.  Set requeue_pi flag only if wait returned 0.
> 	* sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S
> 	(__pthread_cond_wait): Likewise.  Revert handling of EAGAIN
> 	return from futex_wait.
> 	* tst-cond24.c: New test case.
This looks good.  My brain is hurting from reading too much assembly 
code today.  It kept looking to me like the pi-requeued flag as 
uninitialized in the i386 versions, but that was an artifact of mostly 
looking at the diffs.  Once I referred back to the original it was 
pretty obvious what was happening.

FWIW, I haven't seen any complaints since this went into rawhide.

Jeff