Review: Boost.Threads

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

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.

Comments
--------

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

--Beman