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

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.