This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: Race unlocking-locking mutex
- From: David Ahern <dsahern at gmail dot com>
- To: Godmar Back <godmar at gmail dot com>
- Cc: "libc-help at sourceware dot org" <libc-help at sourceware dot org>
- Date: Thu, 12 Sep 2013 09:58:43 -0700
- Subject: Re: Race unlocking-locking mutex
- Authentication-results: sourceware.org; auth=none
- References: <5231ECBE dot 4030006 at gmail dot com> <CAB4+JY+dBDVhk9UJWXRXrxF5BhoTFXv==_v+ibdEBU5Noj4aEw at mail dot gmail dot com>
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.