Re: Thread starvation with mutex

Ok I'll give that a shot and get back to the list.

I don't pretend to understand the scheduling issues and I realise the 
example I gave is somewhat unrealistic of any sanely written 
application, but it just gives me an uneasy feeling that the second 
thread never runs. 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.

Luke.

Perez-Gonzalez, Inaky wrote:

>>From: Luke Elliott
>>
>>Forgot to mention that this is on a UP machine with HT disabled.
>>
>>Can we call it "sensible" instead of fair..?! I think I'll go and read
>>up on some standards. Is there a reason why NPTL does not use this
>>"fair" method? Surely this is pretty normal, expected behaviour of a mutex?
>>    
>>
>
>Would you please give it a shot under RTNPTL 
>(http://developer.osdl.org/dev/robustmutexes) and tell me what happens?
>
>Still you program will fail unless you are in a deterministic scheduling
>policy. In SCHED_OTHER (or SCHED_NORMAL), the priority is moved up and
>down in a certain range of your nice level to accommodate for your CPU
>consumption and improve system responsiveness.
>
>Iñaky Pérez-González -- Not speaking for Intel -- all opinions are my own (and my fault)
>  
>