From: Greg Colvin (greg_at_[hidden])
Date: 2001-01-03 22:56:41
From: William Kempf <sirwillard_at_[hidden]>
> >
> > From: William Kempf <sirwillard_at_m...>
> > > --- 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?
>
> All of them are implemented independent of the thread type(s). Sorry
> if I caused confusion on this point.
Good, thanks.
> > If not, can they be parameterized so that the user of a Boost
> > library requiring synchronization can provide their own
> > implementations?
>
> I see no benefit in this type of approach. It would only lead
> to "reinvention of the wheel" by developers.
>
> > We should not require users to use the Boost threading library
> > when they need thread safety.
>
> Why not? They need not use (nor should they) the thread type(s) in
> this case, but the concepts are so dependent on each other that I
> don't see a benefit in seperating them into seperate libraries, while
> it seems the wrong thing to do.
An example: shared_ptr has long needed a thread-safe counter, and
it makes sense to parameterize shared_ptr on the counter type. I
suspect the Boost thread-safe counter will serve most users fine,
but we can't anticipate every kind of system shared_ptr might be
used in, so we can't anticipate every kind of counter that might
be needed.