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

RE: Thread starvation with mutex

> From: Gary S. Robertson
> 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.
> >
> ..
> 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.

That's something that, TTBOMK, is expected in real-time/embedded
systems, but as Ulrich mentions, it is also slow (as it causes the
convoy phenomenon). Our guess is that the best solution would be 
to have an implementation that can use both, depending on the 

And now, risking Ulrich's second dismissive commentary this month, 
some non-solicited publicity:

That's more or less what we are trying to do with the RTNPTL patch;
we use some twisted evolution of the futex idea to implement a
mutex primitive that can work either enforcing strict ownership
transferal or the quicker version. If you are interested in that
feel free to grep around the mailing list archives, or click to
http://developer.osdl.org/dev/robustmutexes; in the kernel patch
we try to explain all these issues with some detail. I'll be happy
to provide more info if wished.

(btw: the current RTNPTL patch still is not able to switch around
modes, but Boris is busy working on it).

Iñaky Pérez-González -- Not speaking for Intel -- all opinions are my own (and my fault)

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