Race unlocking-locking mutex

[David Ahern]

On 9/12/13 9:52 AM, Godmar Back wrote:
>
> Not a race, at best the possibility of starvation.

It is a race -- you have 2 threads running to the same point the winner 
of which is determined by non-deterministic events. The loser goes to 
the back of the queue. In some situations (single CPU without 
WAKEUP_PREEMPT (linux system)) the case I outlined below causes an 
extreme starvation.

>
> To my knowledge, POSIX doesn't require fair queuing - if you want it,
> implement it yourselves.

And that is why I am asking on the libc mailing list: is this something 
that libc has an interest in addressing as a general infrastructure/OS 
component - providing fairness in access to a resource?

David

>
>
> On Thu, Sep 12, 2013 at 12:33 PM, David Ahern <dsahern@gmail.com
> <mailto:dsahern@gmail.com>> wrote:
>
>     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.
>
>