Re: Threads: what I wrote...

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-08-09 17:00:41

--- In boost_at_[hidden], jsiek_at_l... wrote:
> Dietmar Kuehl writes:
>  > --- Kevlin Henney <kevlin_at_c...> wrote:
>  > [lots on a generic approach]
> 
> Of course I'm also highly in favor of a steering the boost thread
> discussion into a more generic programming approach.
> 
>  > > I'm happy to work out a strawman doc based on this idea and 
building
>  > > on Dietmar's definition's doc, if anyone's interested.
>  > 
>  > I would greately appreciate if I wouldn't be required to write 
>  > everything :-) However, I can offer support on this, be it in 
form of
>  > ideas with respect to requirements, reviews, htmlization of 
text, etc.
> 
> Ok, to help people get a feel for what we want, I've written up a
> strawman concept description for Mutex and ReentrantMutex.
> 
> http://www.lsc.nd.edu/~jsiek/Mutex.html
> http://www.lsc.nd.edu/~jsiek/ReentrantMutex.html

Ahhh... the light goes on.  Sorry, I've not seen this approach to 
design.  When "generic programming approach" was stated I took this 
too mean the implementation should be done through templates.  The 
generic approach from this document seems to mean that the 
implementation is not defined at all, and only certain parts of the 
interface are specified.  The "mutex" may not be a template, but the 
mutex concept is applicable to varying concrete types that may be 
used in templates.  Do I have this right?

The documents look nice, and I like the approach taken for the 
try_lock.  I'm still curious if a timed_lock should be considered.  
The benefit of a timed_lock over a try_lock is that the CPU 
utilization can be vastly reduced for some constructs on some 
platforms.  Yes, that's starting to get specific to the 
implementation, which I don't want to do, but it still seems a valid 
question.

The only comment I'd make on the docs as written at this time is that 
the destructors may need a precondition.  It's possilbe (though 
probably not desirable) to create the lock on the heap and pass it to 
another thread which deletes it.  This means a thread is attempting 
to remove a lock that it doesn't own, which probably should be an 
error?

> Note that with a generic programming approach, when creating 
concepts
> it is better to create lots of fine-grained concepts instead of 
large
> kitchen-sink concepts. For example, the two concepts I've defined do
> *not* say how to create a mutex object, whether by default 
constructor
> or with a name or otherwise. This is left to other concepts.  One
> thing people may want to debate is splitting Mutex even further to
> separate out the support of try locks into a different concept.

Yes, this should be debated, but personally I wouldn't do so.
 
> Also note that having different "valid expressions" is not the only
> thing that differentiates concepts. Semantics, complexity 
guarantees,
> etc. can also make a difference. I've defined Mutex and 
ReentrantMutex
> as different concepts even though they look exactly alike... its 
just
> that their use and behaviour is different enough to highlight with
> different concept names. Note the differences under semantics and
> pre/post conditions.
> 
> One last thing... I suggest the use of terminology from Matt 
Austern's
> book, "Generic Programming and the STL" when it comes to generic
> programming. Use "concept" instead of "interface" and use "model" to
> describe the relationship between a concrete type and concepts for
> which it meets the requirements. Use "refine" to describe the
> relationship between a concept that adds on to another concept.

I definately appreciate this contribution.  We now have an even 
better place to start from.  A little debate and we can see if things 
will work "in the real world".  In fact, I've created an 
implementation of mutex and reentrant_mutex for Win32 threads from 
this document just to play around with the concepts in the real 
world.  Since we're not done debating them I don't think their ready 
for posting, but if anyone's interested in a "toy" to play with as we 
debate I can be persuaded to do so.