This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Race unlocking-locking mutex


On Fri, Sep 13, 2013 at 3:19 PM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 09/13/2013 01:33 PM, Godmar Back wrote:
>> The standard says:
>> "The need to hold spin lock overhead to an absolute minimum also
>> makes it impossible to provide guarantees against starvation similar
>> to those provided for mutexes or read-write locks."
>>
>> What starvation guarantees are they talking about? I thought it meant
>> that an implementation is required to use a FIFO policy if multiple
>> SCHED_RR/SCHED_FIFO threads of *equal* priority are queued on a
>> contended lock.
>>
>> But I also haven't been able to find it explicitly saying so.
>
> I've never seen any guarantees against starvation.
>
> Rich,
>
> Including you here to pick your brain. Has POSIX ever guaranteed
> that mutexes or read-write locks are free of starvation?
>

There are a number of references in the standard & rationale.
Searching for 'starvation', I find for instance

"The need to hold spin lock overhead to an absolute minimum also makes
it impossible to
provide guarantees against starvation similar to those provided for
mutexes or read-write
locks."

But it's not clear at all which guarantees they're referring to.

In the context of rw locks:

"to prevent writer starvation from threads of the same or lower
priority, writers take precedence over readers of the same or lower
priority"

but in the actual section it says only:

"Implementations may favor writers over readers to avoid writer starvation."



> Cheers,
> Carlos.
>
> P.S.
>
> Please avoid top-posting, it's not the common practice here.
> We use bottom/inline posting with trimming as appropriate to make
> the point clear.
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]