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

From: William Kempf (sirwillard_at_[hidden])
Date: 2001-01-03 13:36:08

--- In boost_at_[hidden], "Greg Colvin" <greg_at_c...> wrote:
> 
> 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.
 
> 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.

Bill Kempf