Re: Comments on the thread library

From: williamkempf_at_[hidden]
Date: 2001-03-27 14:30:48

--- In boost_at_y..., Jens Maurer <Jens.Maurer_at_g...> wrote:
> williamkempf_at_h... wrote:
> > > [ Interfaces vs. performance]
> > > >  Unless you think the interface prevents creating
> > > > efficient implementations
> > >
> > > So I believe.
> > 
> > That wasn't clear in your first post.  Care to elaborate?
> 
> As I said before, I believe the user should be able to specify
> his exact features wishes to the mutex. The library will then
> choose either a native implementation or some augmented wrapper
> to provide these features.  The augmented wrapper will likely
> be worse than the native implementation, either in speed or
> in data size.  If the interface prevents passing the user's
> wishes to the library, the implementation is forced to pessimize
> and must assume that the user requires all features, thus choosing
> the (possibly slow and bloated) augmented wrapper more often than
> really necessary.

I'm still extremely hesitant to go with this approach.  If you look 
at the feature diagram there are a lot of features that will not be 
available on all platforms, and some of those can't be emulated.  
Distill it down and you wind up with the three types I've given (with 
possibly a fourth type that includes trylocks but not timedlocks).  
Making a generator for these three (four?) types just complicates the 
design and implementation.  Threaded programming is difficult 
enough.  We should not complicate it with advanced C++ features when 
those features don't really buy us anything.

> > I'm not sure that that's appropriate.  That's why I asked you to
> > explain.  It might be that an implementation needs to use short in
> > order to get hardware supported atomic operations (yes, I know 
this
> > is extremely unlikely since int's are supposed to be the preferred
> > platforms integer size).  In reality I'd expect all 
implementations
> > to use int, but should the documentation be so rigid as to 
preclude
> > short from use for instance?
> 
> Note that bool and char are integral types as well.  Thus, an
> implementation having value_type == bool would be ok under the 
current
> rules, but pratically useless for the user of the thread library.  
As
> it is, atomic_t is generally useless for users striving for
> portability, because they cannot rely on a minimum representable
> range.

The only integral type that should be disallowed is bool, AFAICT.  I 
worry (probably needlessly) that if we specify more than that we'll 
wind up with poor implementations on some exotic platform that has 
atomic operations for chars or shorts but not ints or longs.  As for 
the argument about representable range... portable programs can query 
this through numeric_traits.
 
> [configuration]
> > Or the needed defines are just part of the multitude of
> > makefiles/project files supplied for building.
> 
> Whereever you put the configuration, I'm arguing against
> putting it in config.hpp, because it has a different purpose.
> The distributed .zip file currently gives the impression that you
> should modify config.hpp to adapt Boost.Threads for your platform.

Originally there were three macros, one to indicate that threads 
exist and one for Win Threads and Pthreads implementations 
respectively.  At that point it still seemed config.hpp was 
appropriate.  We've sense grown and I didn't think about the 
implications, and you're right, they don't belong in config.hpp.  
It's convenient to leave them there right now, since we don't have 
any build files yet, but I'll change this before submission.

Bill Kempf