Re: Threads: monitors vs. primitives

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-08-14 11:09:54

--- In boost_at_[hidden], brent verner <brent_at_r...> wrote:
> On 14 Aug 2000 at 08:39 (-0500), jsiek_at_l... wrote:
> | William Kempf writes:
> |  > I think it makes as much sense to nest the CV as it does the 
lock.  
> |  > The CV can't exist with out the mutex, while the mutex can 
exist 
> |  > withou the CV.  Further, the CV is going to be as dependent 
> | > [ clip ]
> |  > >  > while (!full)
> |  > >  >    lock.wait(cv);
> |  > > 
> |  > > while (!full)
> |  > >   cv.wait(lock);
> |  > > 
> |  > > makes a little more sense to me. 
> |  > 
> |  > It makes more sense because it follows the logic of the 
pthreads 
> |  > implementation.  However, I think it makes sense to reverse 
them in 
> |  > our own library because the lock is waiting on the condition.
> | 
> | The fact that the Mutex concept can exist without the CV concept 
is an
> | argument for my position, not yours ;) The Mutex concept should 
not
> | make any mention of a CV. Having a CV typedef nested in Mutex, or
> | having a wait() function in the Mutex's lock would make the Mutex
> | concept dependent on the CV concept, which is the opposite of 
what we
> | want. We want tight coupling, but it should go in the other 
direction.
> 
>    A  condition  variable  must  always  be associated with a
>    mutex, to avoid the race condition where a thread prepares
>    to wait on a condition variable and another thread signals
>    the condition just before the first thread actually  waits
>    on it.
> 
> Having the condition class derive from the mutex class will 
_enforce_
> the required behavior from the (pthreads) condition variable.

The paragraph you quote is actually addressing the fact that 
the "mutex" must be locked before you can wait on the CV.  This is 
addressed by the fact that the CV is passed a "lock" object instead 
of the "mutex" (or the "lock" is passed the CV in its wait() if you 
reverse it).  Inheritance doesn't really seem appropriate here, 
especially since it would lock us into a one-mutex to one-CV idiom.

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.

As for the other issue, whether to put wait() in the CV or the lock, 
I think Jeremy has a stronger argument here.  I still think that 
conceptually it makes more sense to say lock.wait(cv), but the 
coupling is better with cv.wait(lock) and since pthreads are closer 
to the latter I can live with it.