This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: Race unlocking-locking mutex
- From: "Carlos O'Donell" <carlos at systemhalted dot org>
- To: David Ahern <dsahern at gmail dot com>
- Cc: Godmar Back <godmar at gmail dot com>, "libc-help at sourceware dot org" <libc-help at sourceware dot org>
- Date: Fri, 13 Sep 2013 04:53:22 -0400
- 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> <5231F2C3 dot 6080305 at gmail dot com>
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:
>>
>>
>> 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.
It's a race only the strictest sense of the definition. We mostly
refer to races when we are talking about bugs, but a race need not be
a bug.
I agree there is a race, but not a bug.
>> 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.
You can always make a proposal and send it to
libc-alpha@sourceware.org to have it discussed?
Cheers,
Carlos.