Thread Synchronization (Was Re: Sockets vs. net connection)

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