[boost] Re: Threads: monitors vs. primitives

From: jsiek_at_[hidden]
Date: 2000-08-14 13:15:11

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.

 > 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.

Cheers,

Jeremy

----------------------------------------------------------------------
 Jeremy Siek                        www: http://www.lsc.nd.edu/~jsiek/
 Ph.D. Candidate                  email: jsiek_at_[hidden]
 Univ. of Notre Dame         cell phone: [phone]   
----------------------------------------------------------------------