Race unlocking-locking mutex
Ángel González
keisial@gmail.com
Fri Sep 13 19:16:00 GMT 2013
On 13/09/13 10:53, Carlos O'Donell wrote:
> On Thu, Sep 12, 2013 at 12:58 PM, David Ahern<dsahern@gmail.com> wrote:
>> On 9/12/13 9:52 AM, Godmar Back wrote:
>>> 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?
> A ticket lock system is fairly easy to implement on top of a mutex.
>
> I expect that glibc will only be interested in an implementation if
> you can show a considerable performance boost for having the library
> implement the ticket lock.
Even though "the scheduling policy shall determine which thread shall
acquire the mutex", it seems weird that the thread which ends up
acquiring the mutex is not one of the threads which were blocked waiting
on it.
David problem should be solved if the unlock atomically assigned it to
the waken thread (instead of waiting for it to reacquire the mutex).
However, as it is a kernel decision, I think it would require a new
futex operation, which stored in uaddr2 the waken tids. Then
mutex->__data.__owner could be passed as uaddr2 and the mutex considered
also locked if owner != 0.
There's an interesting reading at https://lwn.net/Articles/267968/
(Ticket spinlocks), including some impressive numbers. The kernel
spinlocks were having pretty much the same problem, with the processor
which released the spinlock reacquiring it before the waiters (probably
due to owning the cache line).
Cheers
More information about the Libc-help
mailing list