From: Peter Dimov (pdimov_at_[hidden])
Date: 2006-09-21 12:38:52
David Abrahams wrote:
> OK, so here's what I think I missed: B is blocking on a resource. The
> scheduler only distributes the running role among the ready threads.
> If B never becomes ready, it starves. The only way B can become ready
> is if A releases its lock to the system, so I guess the question is,
> does A's unlock actually move B into the ready state, or at least
> cause the scheduler to try to ready B in its next timeslice?
A's unlock has to wake up B (otherwise it will never run, even though the
mutex is free), so yes. The only flaw in the ointment ( :-) ) is if the
scheduler decides to preempt A while it's inside the critical section. But
this is a general problem with any mutex scheme; if threads are frequently
preempted while holding a lock, then that lock's granularity is wrong and
the application needs to be redesigned.
The same situation can occur with three threads, by the way:
>>>> A: lock [lockcount == 0]
>>>> B: lock [lockcount == 1, slow path]
>>>> A: unlock [lockcount == 0, slow path/post sema]
>>>> C: lock - [lockcount == 1, slow path]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk