Re: Thread starvation with mutex

Ulrich Drepper wrote:

>Luke Elliott wrote:
>
>>Is there a reason why NPTL does not use this
>>"fair" method?
>>
>
>It's slow and unnecessary.
>
>
>>Surely this is pretty normal, expected behaviour of a mutex?
>>
>
>Perhaps expected by you.  Anybody with thread experience wouldn't expect it.
>
As an embedded systems software engineer, I've been developing complex 
systems based upon lightweight processes or 'threads' for some 
twenty-five years now.  For the past five years I have been working with 
POSIX threads on Solaris and Linux.  The ambiguities of the Linux 
scheduler's dynamic priority manipulation notwithstanding, I would 
indeed expect that a FIFO-queued mutex would allow Mr. Elliot's 'thread 
2' to acquire the mutex once it was released... the majority of the 
threaded environments with which I have worked would in fact guarantee 
that, given two threads of equal priority.

For Mr. Elliot's edification, in simplifed plain English, POSIX 
basically says that a mutex will be acquired by the highest-priority 
process or thread waiting on it IF multiple priority levels are 
supported.  It doesn't necessarily stipulate the queing behavior when 
the waiters all have the same priority.  In a nutshell, thread 2 in this 
instance is being 'shut out' because it's easier and faster to give the 
mutex back to the thread which just released it.  In essence, nptl is 
allowing thread 1 to release the mutex and then 'snatch it back' before 
the kernel gets a chance to wake up thread 2 and let it acquire the 
mutex.  The puzzle is, the scheduler should be dynamically elevating 
thread 2's priority while it is blocked waiting on the mutex, so 
eventually it should be able to acquire the mutex based upon its 
elevated priority (according to POSIX), - and this doesn't seem to be 
happening!