Boost logo

Boost :

From: William Kempf (sirwillard_at_[hidden])
Date: 2001-01-03 11:54:07

--- In boost_at_[hidden], Beman Dawes <beman_at_i...> wrote:
> At 03:49 PM 1/3/2001 +0000, William Kempf wrote:
> >The Boost Thread Library (final name?) is very much a work in
> >progress. Things slowed down in the last few months because of
> >holidays and other pressing matters, but I'll be stoking the fires
> >again real soon.
> >
> >You comments about needing thread safety brings up a topic for
> >discussion, however. Early in the development we talked about
> >being a need for synchronization primitives even before we include
> >portable thread support. We're basically close enough now to
> >on porting such primitives to various platforms and submitting an
> >initial version of the library to Boost. My focus had moved on to
> >TLS and thread support rather than on finishing the
> >primitives, but maybe we should consider doing just this. Any
> >thoughts from others on this?
> Rather than waiting for a single perfect library, would it move
> along faster if you separated the architecture into two or three
> (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.
It's only useful to stop gap in order to allow developers to write
libraries that will be "thread safe" when the users write programs
using the libraries in code that uses native threads. We've seen a
couple of libraries already considering this, including a submission
that uses it's own synch primitives as a temporary solution to the

I can see submitting the two components at seperate dates, but they
are too tightly coupled to truly be seperate libraries, I think.

> Aside from technical issues, that would give the impression of
> with the attendant social engineering benefits.

This differs from the stop gap approach how?

Bill Kempf

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