Re: [boost] Re: Comments on the thread library

From: Jens Maurer (Jens.Maurer_at_[hidden])
Date: 2001-03-27 12:08:41

williamkempf_at_[hidden] 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.

[seconds and nanoseconds for timeouts similar to POSIX timespec]
> In C++ I wouldn't pass a structure for this.  I'd pass two longs.
> That aside, this is not totally unreasonable, excepting the next
> point.

A structure could have overloaded operators, e.g. to add durations.
However, the details of this seem to be out-of-scope for a threads
library.

> 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.

[use shared_ptr<mutex> or similar for controlled dynamic allocation]
> any noncopyable type... allocate it on the heap, probably controlled
> by a wrapper such as shared_ptr. 

Ah, good point.  I think it's worth spending a sentence on that
in the docs.

> It seems to me that what you're really getting at is that you'd
> prefer the types to be copyable.  This opens up a huge can of worms.

Agreed.

[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.

> That's why I think it's better to do it in the build system.  Hacking
> any header for this level of information is going to be very
> difficult to do given the little bit of info available to the
> compiler.

The compiler usually has predefines for the CPU, the operating
system (occasionally with version info), and sometimes the C library
version.  This seems go a long way to choose the correct threads
support.

Jens Maurer