Re: Comments on the thread library

From: williamkempf_at_[hidden]
Date: 2001-04-03 08:45:36

--- In boost_at_y..., "Greg Colvin" <gcolvin_at_u...> wrote:
> From: Beman Dawes <bdawes_at_a...>
> > The suggestions to add features (via generative programming or 
otherwise) 
> > make me very nervous.

First, thanks Beman for expressing what I tried to much more 
succinctly and elegantly.  Generitive approaches add complexity, both 
for the user and for the implementor.  In many cases the benefits far 
outweigh this cost, but in this case I don't think that will turn out 
to be true.  *Any* added complexity for the user is a bad thing here.

> > Multi-threading is notoriously difficult to get right.  The 
experts as far 
> > back as Dijkstra, Hoare, and Brinch Hansen have argued time and 
time again 
> > for minimalist approaches to concurrent programming.
> > 
> > Keep examples like std::basic_string<> in mind.  It tried to make 
all users 
> > happy, even though needs and wants varied a great deal.  The 
result was 
> > general unhappiness.
> > 
> > Keep Boost.Threads simple.  Don't try to solve every multi-
threading 
> > problem the first release.  It just isn't the right library to 
use as an 
> > experiment in new techniques like generative programming.  Or to 
load up 
> > with features for everyone.  Just my opinion, of course.
> 
> I hate to argue against K.I.S.S., and I don't have an opinion
> on whether or not a mutex generator is the way to go, but it
> does seem that we have already decided against the Hoare/Hansen
> approach of a minimal language extension in favor of a set of
> lower-level primitives.

This is not precisely true.  We can't provide a language extension, 
only a library extension.  Other than that, the decision to provide 
lower-level primitives was made for two reasons:  1) there are 
several higher-level concepts to choose from and there's no concensus 
as to which of these is "the one true path to enlightenment" (CSP is 
one promising path, for example) and 2) any of the higher level 
concepts are going to require lower level primitives to implement 
them.  The goal is to provide the lower level primitives to be used 
as the building blocks for several higher level concepts.  
Hoare/Hansen do the same, only on a different scale since they're 
providing language extensions for specific higher level concepts.
 
> I'll also point out that one can first develop a set of classes
> and later devise a generator for that set, so we may not need to
> choose right away.

I'd very much agree with this.

Bill Kempf