Race unlocking-locking mutex

[David Ahern]

We are seeing a race condition in mutex unlock/locking where one thread 
is hogging access to a mutex. It is a contended mutex with a queue of N 
(N = between 3 and 5) threads waiting for the lock. The thread holding 
the lock (thread 1) releases it and in the process wakes up a thread 
(thread 2).

Thread 1 continues its processing which includes wanting the mutex again 
and acquires it before thread 2 can be scheduled, return to userspace 
and grab the lock. This means thread 2 returns to futex(WAIT) and even 
worse goes to the back of the queue.

This raises a number of questions, the first of which is shouldn't 
thread 1 be forced to the queue on a contended lock? ie., why is it 
allowed fastpath access?

David

PS. I am not subscribed to libc-help mailing, so please cc me on responses.