[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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!

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]