Re: Thread starvation with mutex

Perez-Gonzalez, Inaky wrote:
> > Note that Rusty's futex library does offer both.  The kernel's futuex
> > primitive is capable of strict ownership transferral in FIFO order.
> >
> > Sometimes you want immediate ownership transferral, but in a more
> > efficient "fair" but not FIFO, or RT (which is not always fair) order.
> 
> Hmmm...how? Are you referring as in waking the waiter without
> unlocking the futex in user space? 

Yes.

> I don't really see it very clear, I am kind of very thick now -- please 
> be patient with me---I've slept three hours only

I know the feeling, so I will be quick..

FUTEX_WAKE returns a value indicating the number of threads actually
woken.  So the first thread calls FUTEX_WAKE with parameter 1: if that
returns 0, it unlocks the userspace word, otherwise it leaves the
userspace word unchanged.

FUTEX_WAIT returns a status indicating whether we waited and were
woken by someone calling FUTEX_WAKE.  If we were woken like that, and
the userspace mutex is known to be of an "ownership transferral" kind,
we now own the mutex.

The kernel futex is careful to ensure the number returned by
FUTEX_WAKE _exactly_ matches the number of FUTEX_WAIT callers which
return the woken-by-waker status.

> Did you give me that feedback before or did I just miss it? It is
> _very_ simple to add that functionality (in fact, it is a one or
> two liner). I had never really thought of adding it because nobody
> asked for it (or because I never realized somebody did).

I have mentioned it before on phil-list.  Ulrich said he understood
but it wasn't useful for NPTL.  And it _has_ been in Rusty's original
futex-2.2 library, which predates NPTL (I would never have thought of
it without Rusty's code - matching the numbers in the kernel is clever).

(If you use FUTEX_FD instead of FUTEX_WAIT it becomes unreliable, but
your mutex primitives don't need to do that.  That's a flaw in
FUTEX_FD which I would dearly like to fix when I have time).

-- Jamie