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

From: William Kempf (sirwillard_at_[hidden])
Date: 2001-01-03 11:54:07

--- In boost_at_[hidden], Beman Dawes <beman_at_i...> wrote:
> At 03:49 PM 1/3/2001 +0000, William Kempf wrote:
> 
>  >The Boost Thread Library (final name?) is very much a work in
>  >progress.  Things slowed down in the last few months because of 
the
>  >holidays and other pressing matters, but I'll be stoking the fires
>  >again real soon.
>  >
>  >You comments about needing thread safety brings up a topic for
>  >discussion, however.  Early in the development we talked about 
there
>  >being a need for synchronization primitives even before we include
>  >portable thread support.  We're basically close enough now to 
focus
>  >on porting such primitives to various platforms and submitting an
>  >initial version of the library to Boost.  My focus had moved on to
>  >TLS and thread support rather than on finishing the 
synchronization
>  >primitives, but maybe we should consider doing just this.  Any
>  >thoughts from others on this?
> 
> 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.  
It's only useful to stop gap in order to allow developers to write 
libraries that will be "thread safe" when the users write programs 
using the libraries in code that uses native threads.  We've seen a 
couple of libraries already considering this, including a submission 
that uses it's own synch primitives as a temporary solution to the 
problem.

I can see submitting the two components at seperate dates, but they 
are too tightly coupled to truly be seperate libraries, I think.

> Aside from technical issues, that would give the impression of 
progress 
> with the attendant social engineering benefits.

This differs from the stop gap approach how?

Bill Kempf