Re: [boost] Boost.Thread and extensibility

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2007-12-20 16:06:11

On Dec 20, 2007, at 9:38 AM, Eames, Andrew wrote:

> Hi,
>
> I've been continuing my quest to try and use Boost for my DSP and its
> C++ compiler. I've been looking at Boost.Thread and it seems that it
> relies on one of a fixed few threading libraries to exist. I have my  
> own
> native implementation of mutexes etc. and it doesn't seem like there  
> is
> any easy way to plug it in without editing a lot of the boost  
> source. Is
> this an issue that has been raised before?

There is an ongoing effort to standardize a variation of the boost  
threads lib, most recently documented here:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2447.htm

Part of the motivation for the departure from the boost::threads API  
is to allow client-defined mutexes work with std::defined locks and  
condition variables.  Anthony Williams has been updating the  
boost::threads lib on the boost main svn trunk, taking into account  
the standards work.

This paper:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2406.html

has a good rationale for the current mutex/lock and condition variable  
design, though a few of the names have changed since this paper was  
written.  The opening paragraph for the Mutex Rationale in this paper  
is:

> The overall intent of the above design is to allow user defined  
> mutexes to work with standard defined locks, and to also allow  
> standard defined mutexes to work with user defined locks. The  
> standard defined mutexes and locks create mutex and lock concepts,  
> which if followed allow for the interoperability between user  
> defined and standard defined components (much like our existing  
> containers and algorithms interoperate with user defined containers  
> and algorithms).

-Howard