From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-08-03 14:31:10
At 12:26 PM 8/3/2001, John Max Skaller 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk