Re: Thread starvation with mutex

Perez-Gonzalez, Inaky wrote:
> 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 
> application).

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.

> 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.

You don't need RT futexes to get strict mutex transferal - standard
futexes can do that, you just need a different userspace.

RT futexes are good for some RT purposes, but they have their own
problem (which is why I didn't encourage the simple RT futex patch
into 2.6): they _break_ strict mutex transferal when the desired
sementic is FIFO.

Btw, this problem of mutex/futex starvation appears at another level
in the system: spinlock starvation.  Sometimes one CPU's spinlock will
starve another CPU even though the first is repeatedly releasing and
reacquiring the spinlock.  It is a known problem in the Linux kernel,
which is fortunately rare enough to not be a problem, except in some
rare cases which have been worked around.

-- Jamie