Re: [boost] win32 mutex and condition variable algorithms

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]