Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-08-31 15:14:11

I believe William Kempf's Boost.Threads submission should be accepted by

Bill deserves a great deal of credit for patiently working through a large
number of issues, for discussing the issues at length and over an extended
period of time, and for making changes to the library when indicated.

A really large number of people helped him. Be sure to look at the
Acknowledgements page in the docs.


* The design goals seem to have been met, including the safety goals that
are particularly important to me.

* While a number of alternate designs for portions of the library have been
discussed, none seem enough better to warrant delay. The alternatives have
been beaten to death and it is time to move forward.

* In general, the design seems of reasonable size and functionality to
me. While there may be legitimate questions about the inclusion of some of
the classes (see next comment), the design has not become bloated with
marginally useful features and functions as happens all too often.

* I share Peter Dimov's concerns about semaphore. A long time ago I asked
on comp.programming.threads if Boost should avoid any features as too error
prone. The one suggestion I got was to avoid semaphores. While semaphore
is documented in Boost.Threads as dangerous, perhaps we should remove it
entirely or move it to an implementation namespace.

* There are many functions where a reasonable implementation may wish to
allocate memory. These should be documented as potentially throwing
std::bad_alloc. Like the standard library, it seems to me this can best be
done with a blanket "any function may throw std::bad_alloc" statement
rather than try to guess which functions an implementation may wish to do
dynamic memory allocation.

* It seems to me that some implementations may run out of resources (other
than memory) in the constructors for almost any of the Boost.Thread
classes. Thus I think there should be a blanket statement that all
constructors can potentially throw thread_resource_error. If a blanket
statement isn't included, at least semaphore and the mutex constructors
seem to me to need to allow throwing thread_resource_error.

* class thread_resource_error needs documentation.

* class xtime needs documentation.

* A tutorial would be helpful, although certainly not necessary right away.

* Jens Maurer's bounded queue should be included at least as sample code if
not as part of the library itself.

* Once Boost.Threads is accepted, and thus the interfaces stable, let's
quickly try to find implementors for platforms other than Win32 and Linux,
and get them to contribute their implementations to Boost.

* I've used (an earlier version of) the Boost.Threads code to produce a
multi-threaded version of an existing industrial program. It ran correctly
right away, and was 40+ percent faster on a dual processor machine than the
single threaded version. I'd never done any multi-threading previously.

* I haven't reviewed the Boost.Threads code in detail, but what I have
looked at seems reasonable and meets our agreed upon guidelines. Hopefully
some other reviewer will go over the code with a fine-toothed comb.



Boost list run by bdawes at, gregod at, cpdaniel at, john at