From: William Kempf (sirwillard_at_[hidden])
Date: 2001-01-04 09:44:31
--- In boost_at_[hidden], "Greg Colvin" <greg_at_c...> wrote:
> From: William Kempf <sirwillard_at_m...>
> > > 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.
A thread safe counter is, for the most part, a thread safe counter.
The implementation of this counter shouldn't make a difference here.
I can't see any case in which the simple atomic counter won't work,
especially for this specific case. (BTW, you'll need more than just
a thread safe counter in at least one key place in shared_ptr where a
Mutex will be needed.)
Now *IF* you can come up with some reason why a different counter is
needed this other counter must be a radically new type. In this case
you'll need to implement it from the ground up (possibly using other
synch primitives from the Boost library), and the new counter will be
a likely candidate for inclusion in the thread library.
Again, I see no reason to view inclusion of the thread library as a
bad thing for creating thread safe libraries.
Bill Kempf