This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: Race unlocking-locking mutex
- From: Godmar Back <godmar at gmail dot com>
- To: "Carlos O'Donell" <carlos at systemhalted dot org>
- Cc: David Ahern <dsahern at gmail dot com>, "libc-help at sourceware dot org" <libc-help at sourceware dot org>
- Date: Fri, 13 Sep 2013 09:53:23 -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> <CAE2sS1gp9Z5b5qoSqgBXbbL-S+_fHaL1PN7z=CfMsqSTA=7LFg at mail dot gmail dot com>
BTW, I checked 1003.1 the 2008 version.
It says:
"The pthread_mutex_unlock() function shall release the mutex object
referenced by mutex. The
manner in which a mutex is released is dependent upon the mutex’s type
attribute. If there are
threads blocked on the mutex object referenced by mutex when
pthread_mutex_unlock() is called,
resulting in the mutex becoming available, the scheduling policy shall
determine which thread
shall acquire the mutex."
In other words, SCHED_FIFO & SCHED_RR scheduled threads will provide
the necessary behavior.
Does GNU Libc implement that?
- Godmar
On Fri, Sep 13, 2013 at 4:53 AM, Carlos O'Donell
<carlos@systemhalted.org> 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:
>>>
>>>
>>> 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.