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
> > is extremely unlikely since int's are supposed to be the preferred
> > platforms integer size). In reality I'd expect all
> > to use int, but should the documentation be so rigid as to
> > 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
> rules, but pratically useless for the user of the thread library.
> it is, atomic_t is generally useless for users striving for
> portability, because they cannot rely on a minimum representable
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.
> > 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk