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

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.




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