Boost logo

Boost :

From: Greg Colvin (greg_at_[hidden])
Date: 2001-01-03 11:56:28


From: William Kempf <sirwillard_at_[hidden]>
> --- In boost_at_[hidden], Beman Dawes <beman_at_i...> wrote:
> ...
> > Rather than waiting for a single perfect library, would it move
> things
> > along faster if you separated the architecture into two or three
> sections
> > (or levels, if that makes more sense), and then finalized a
> submission for
> > the most basic?
>
> I'm not sure I follow you here. The seperations I see as a
> possibility is for synchronization types and the thread
> creation/manipulation type(s) to be seperated. However, this
> seperation makes sense only as a stop gap approach for developers
> only interested in making their libraries "thread safe". With out
> threads the synchronization primitives are pointless, and with out
> the synchronization primitives it's very difficult to use threads.

Can't at least some of the thread synchronization primitives
be implemented so that they work no matter how the threading
is done?

If not, can they be parameterized so that the user of a Boost
library requiring synchronization can provide their own
implementations?

We should not require users to use the Boost threading library
when they need thread safety.


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