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

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)






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