Re: boost.threads

From: John Max Skaller (skaller_at_[hidden])
Date: 2001-08-03 11:26:21

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?
When are the processor caches flushed?

        Such synchonrisation points must occur at certain
calls to library routines: this is the 'moral' equivalent
of sequence points, except the aliasing problem is much more severe.

        Which is why we need a library.
The reader should note that things that work fine on
a single CPU system might not work with multiple CPUs.
On the other hand, flushing processor caches is EXPENSIVE.

-- 
John (Max) Skaller, mailto:skaller_at_[hidden] 
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
New generation programming language Felix  http://felix.sourceforge.net
Literate Programming tool Interscript     
http://Interscript.sourceforge.net