Re: Thread starvation with mutex

Perez-Gonzalez, Inaky wrote:
> 1. Thread A calls FUTEX_WAKE
> 2. Thread A receives 0 from FUTEX_WAKE
> 3. Thread A atomically unlocks the user space word
> 
> Now, if some Thread B comes in between 2 and 3 and tries to
> lock, it will see the user space word locked and go down to
> wait in the kernel. It will sit there for ever because 
> in (3) the word is locked and nobody knows B is there sleeping.

After step 2, Thread B sees the user space word is locked and does an
atomic decrement (or whatever) to indicate that there is a waiter, as
usual.

In step 3, Thread A tries to unlock by doing an atomic copmare and
exchang, and then it sees that the word indicates there is a waiter,
so loops back to 1.

> > 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).
> 
> [confused] Are you talking about the FIFO unlock order or the strict
> ownership transferal? (I was talking about the FIFO).

[me confused too] In that text I'm talking about strict ownership
transferral, but in other emails on this thread, specifically when
mentioning RT futex, I've been talking about FIFO wakeup order.

-- Jamie