This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Race unlocking-locking mutex
- From: David Ahern <dsahern at gmail dot com>
- To: libc-help at sourceware dot org
- Date: Thu, 12 Sep 2013 09:33:02 -0700
- Subject: Race unlocking-locking mutex
- Authentication-results: sourceware.org; auth=none
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.