[boost] Re: Threads: monitors vs. primitives

From: jsiek_at_[hidden]
Date: 2000-08-14 11:38:39

Suppose there is a thread library implementation that provides a mutex
class but not a condition variable class. Why would you want to
require that their mutex class have a nested typedef for a
non-existent condition variable class?

William Kempf writes:
 > I've thought carefully about what Jeremy has said, and it is a valid 
 > argument.  I still don't know that I agree with it, however.  We've 
 > nested the lock class within the mutex.  Why?  The mutex concept can 
 > exist with out the lock concept (though that would require making 
 > public lock/unlock methods... but I don't find that to be a 
 > compelling enough reason to embed the lock).  To my mind we nested 
 > the lock because it depends strongly on the implementation of the 
 > mutex.  The same is true of the CV.  I see no physical or logical 
 > constraints placed on us by embedding the CV, while I like the 
 > bundling.  After all, the CV can't exist with out the mutex, so it 
 > makes sense to make it an embedded type to me.