Re: Thread starvation with mutex

Jamie Lokier wrote:

>I agree with that design.  I'm surprised the kernel is not scheduling
>the second thread in the example.
>
>As I said at the start of the thread, I'd expect thread 2 to be
>starved on an SMP box, but the test box is UP.  I've just read
>kernel/sched.c where it seems clear that a thread that's been sleeping
>for a long time and then woken will immediately preempt its waker.
>(Unless it's a synchronous wakeup, but futex wakeups are not).
>
>In this case, thread 2 is starved but it must be periodically waking
>and then immediately sleeping as it fails to acquire the mutex.  If
>the kernel's dynamic priority calculation isn't giving priority to
>thread 2 so that it runs as soon as thread 1 calls futex_wake, there
>is a problem with that calculation.
>
>-- Jamie
>
>  
>
This has been fun, hasn't it? The list has been quiet for too long!

In the example the first thread does:

lock mutex
usleep
unlock mutex

As someone pointed out (off list I think), if the sleep is replaced with 
a busy loop, the second thread will run.

Now clearly the original example is totally unrealistic, but is the fact 
that the second thread never runs something that could happen in the 
"real world"? I guess that depends on whether the thread blocked on a 
mutex can assume at some point it will get woken ... (Interestingly, AIX 
apparently shows the same behaviour as NPTL.)

Luke.