Re: Threads: monitors vs. primitives

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-08-14 14:14:44

--- In boost_at_[hidden], jsiek_at_l... wrote:
> William Kempf writes:
>  > --- In boost_at_[hidden], jsiek_at_l... wrote:
>  > > 
>  > > 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?
>  > 
>  > I don't follow this.  We're defining the library here.  We can 
decide 
>  > that the mutex class must have a CV class.  What other libraries 
have 
>  > defined makes no difference here.
> 
> Actually, at this stage we are *not* defining the library. We are 
just
> defining a set of concepts. Concepts are always completely open-
ended.
> They can be implemented in lots of different ways, by lots of
> different concrete types. Boost will have an implementation, but I
> would be disappointed if there were not other implementations as
> well. By carefully designing the concepts, we don't force other
> implementations into a "all or nothing" situation.

I guess I agree with this, though I still have problems resolving it 
within context of your argument.

>  > Even if you were to argue that we may have a "mutex type" that 
won't 
>  > have a corresponding CV (sounds like a mistake to me, but let's 
use 
>  > this argument), what's preventing you from simply not including 
the 
>  > nested CV in this case?  I don't see how this is any different 
from 
>  > the iterator concept having classifications that indicate what 
>  > functionality is included.
> 
> This suggestion makes more sense, but it is very different from what
> you were saying before.
> 
> What I thought your were proposing before was this:
> 
> concept Mutex
>   associated types:
>      X::lock  
>      X::condition_variables
> 
> 
> And what you are now proposing is more like this:
> 
> concept Mutex
>   associated types:
>      X::lock  
> 
> concept MutexWithCV refines Mutex
>   associated types:
>      X::condition_variable
> 
> 
> This is OK with me, since it doesn't place condition variable inside
> Mutex. However, I think MutexWithCV is a bit unnecessary... why not
> express the coupling in the ConditionVariable class. We currently
> do not have a very precise way of describing this kind of coupling,
> but I'm sure I could add some prose that gets the idea across.

This supposes that there's ever a reason to have a Mutex instead of a 
MutexWithCV.  I'm not sure that the plain Mutex concept is ever 
really valid.  I realize that this is a shakey argument on my part, 
so maybe I should abandon it.  I guess I just don't feel good doing 
that just yet.  The nesting appeals to me, and I guess it will 
continue to until you can point out why it's appropriate for lock but 
not for condition.  Or, put in another way, why would we ever have a 
concrete mutex type with out an associated concrete condition type?