Re: Not keen on Boost.Threads? [was: name of the "thread" type]

From: williamkempf_at_[hidden]
Date: 2001-06-23 12:06:02

--- In boost_at_y..., Ross Smith <ross.s_at_i...> wrote:
> Beman Dawes wrote:
> > 
> > Ross Smith wrote:
> > 
> >  >(Then again, possibly I'm not the best guy to be putting his 
oar in at
> >  >the moment; I'm not very keen on what I've seen of the Boost 
threads
> >  >library so far, so clearly your aims are different to mine.)
> > 
> > Could you explain why you aren't "very keen"?
> > 
> > Because the library isn't cast in concrete yet, knowing what 
people dislike
> > about it would be helpful.
> > 
> > If it is a matter of philosophy or aims rather that design 
details, that is
> > important and helpful.  We need to understand other views.
> 
> Well, judging from the current partial implementation, it's partly 
that
> it seems a bit too heavyweight -- something of a "kitchen sink"
> approach, trying to put every conceivable need into the API. I'd 
prefer
> something a bit more spartan.

Care to elaborate.  What's included is mostly the "core" threading 
concepts.  One of the only real exceptions I can think of is the 
inclusion of recursive mutexes, but for C++ I think these are nearly 
a neccesity.

> It also seems to be following the pthreads architecture too closely 
for
> my taste. It doesn't really "feel" like a designed-from-scratch C++
> library to me -- more like a thin OO wrapper around the pthreads 
API,
> and an attempt to emulate it on Windows. (I'm thinking in 
particular of
> condition variables, a pthread-specific concept that I don't think
> belongs in a generic threading library.)

This is ironic.  I'm the main developer on this (though I've gotten a 
lot of input from others) and I'm a Win32 programmer with little 
experience with pthreads.  The only thing in the library that is 
pthread-like instead of Win32-like is the condition variables, and 
this happens to be a major lacking in the Win32 API.  I don't know of 
any serious MT programmers on the Win32 platform that haven't rolled 
their own CV concepts because of this.  The CV concept is _required_ 
to use a monitor pattern, which is one of the most flexible and easy 
to use synchronization concept in OO programs.

In fact, I'd expect more people to accuse the design of being too 
Win32 biased.  For instance, the design of the Semaphore includes a 
max setting and methods to increase the semaphore value by variable 
amounts instead of one at a time.  Another example is the design of 
the thread class itself, which allows for multiple join() calls and 
has no concept of detach().  I could continue with this list, but I 
think you get my point.
 
> (When I have a bit more spare time, I'll polish up my own thread 
library
> and post it somewhere for comparison.)

I'd be interested in seeing this, but it may be better for you to 
point out specific things in the current implementation you'd do 
different.

Bill Kempf