Boost logo

Boost :

From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2006-04-10 16:26:32


>> I think all desired modifications can be proposed in the current
>> Boost Thread rework effort and aren't too intrusive. For thread
>> launching I prefer Kevlin Henney's proposal approach. Has the
>> committee rejected this approach?
>
> You are not alone. The problem is that Kevlin is a very busy man, and
> has not yet produced a full working proposal. Likewise, I am not aware
> of a freely available reference implementation, whereas there are at
> least 3 known separate implementations of the Boost threads interface.

There is a partial implementation (threader, joiner and lockable) I
wrote some months ago:

http://boost-consulting.com/vault/index.php?&direction=0&order=&directory=Concurrent%20Programming

See thread_ex.2005-08-31.zip. It's constructed above Boost.Thread. I
didn't know then Boost.Thread's had unlock() function so I had to make
ugly things to access Boost.Thread's mutex private functions. But the
thread launcher is implemented with Boost.Thread and shared_ptr.

> The approach has not been rejected, but is unlikely to make it in time
> for TR2. Likewise, the thread library itself is most likely destined
> for TR2 rather than C++0x, although I believe the evolution group would
> prefer us to be more aggressive on this.

We can implement thread launching interface above Boost.Thread, as in
the wrapper I wrote. Using that wrapper to launch threads and condensing
6 mutex types into 2 it's possible for TR2. We can let read write mutex
(or shared_mutex, if you prefer that name) for C++0x along with a
message queue. I will look to Pete's paper to propose changes to Boost
mailing list (including Howard Hinnant's lock reduction).

> TR2 is shaping up nicely as a library offering system-services though,
> with FileSystem accepted, and threads and networking strongly under
> consideration. Beeman's approach to error reporting for
> system-specific errors could be broken out of FileSystem and become the
> underpinning mechanism shared across all TR2 system-level libraries.

I'm trying to follow also that error reporting system with
Boost.Interprocess, and I must say that I find that approach good in
general.

Regards,

Ion


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk