Re: [boost] Re: boost.threads

From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-08-03 14:31:10

At 12:26 PM 8/3/2001, John Max Skaller wrote:
 >williamkempf_at_[hidden] wrote:
 >
 >> Yes, and with valid reason.  C++ is not C.  Some things that make
 >> sense in a C API are either difficult to live with in C++, or even
 >> result in conflicts with the language design.
 >
 >	I support Bill's approach. I'd like to remind people
 >that we're actually talking about defining a threading library
 >that works for a yet to be determined extension of the C++
 >abstract machine. The relationship with Windows and POSIX
 >threading should be that those models can be used to implement
 >the C++ model. Conversely, the C++ model must provide at least
 >minimal support for real threading requirements as both
 >Windows and POSIX models do.
 >
 >> Firstly, it's not a mix of two APIs.  Everything here is designed
 >> from the ground up.  Usage patterns and known problems/strengths for
 >> all (not both, other libraries than POSIX and Win32 have been
 >> considered, including from other languages) have been paid attention
 >> to, but none of them are the basis for Boost.Threads.
 >
 >	I think this approach is the only feasible one.
 >Designing a new threading model is necessary. Obviously,
 >existing models should be used as input data in making
 >the design decisions, but it seems to me Bill is doing that.
 >
 >	The purpose of the library (and abstract machine extensions)
 >isn't to do POSIX or Windows threading, but to introduce concurrency
 >into C++. Since concurrent execution is _intrinsically_ bound up
 >with language semantics -- it is after all a fundamental concept
 >to have concurrent threads of control -- I'd like to think those
 >with expertise will help Bill in his effort.
 >
 >	In particular, we need a library to see what changes
 >are needed to the core language to make concurrency work: Beman
 >has already outlined a synchronisation model in his paper.
 >The key issue involves sharing data: if a thread writes to
 >some shared memory, how can another thread read that data?

Yes, what Butenhof in "Programming with POSIX Threads" (highly recommended 
reading) calls "Memory visibility between threads" will have to be a key 
part of the core language specification.  This is definitely going to need 
help from John and other core language experts.

--Beman