Re: Thread starvation with mutex

Luke Elliott wrote:
> I would expect something like this:
> 
> 1. Thread 1 acquires mutex
> 2. Thread 2 tries to acquire mutex, is put on wait queue for mutex
> 3. Thread 1 releases mutex, but say thread 2 isn't scheduled (fair enough)
> 4. Thread 1 attempts to acquire mutex again but the wait queue isn't 
> empty, is added to the wait queue and the thread sleeps
> 5. Thread 2 wakes up...
> 
> But clearly at stage 4, thread 1 successfully acquires the mutex.

Step 4 is due to NPTL's mutex design:

    - After releasing a mutex the userspace word is whatever value
      represents "free".

    - At step 4 NPTL decides to acquire the mutex; it doesn't check
      for other pending waiters because only the kernel knows about them
      and NPTL does not enter the kernel if avoidable.

But even that shouldn't result in thread 2 _never_ running.

I am surprised thread 2 is never schedule at point 3.  It should have
a high dynamic priority because it has been sleeping for such long
time.  Perhaps there is a bug in the scheduler?

Do you get the same results with "sleep 10" instead of "sleep 2"?

What does "top" show while these two threads are running?

-- Jamie