Meyer, OO and concurrency

[David Hopwood]

Taj Khattra wrote:
> On 7/14/05, Joe Armstrong (AL/EAB) <joe.armstrong@REDACTED> wrote:
> 
>>Threads/process in C++ are usually not C++ Threads or processes but
>>thinly disguised OS threads or processes.
>>
>>The problem with this is that the semantics of the program is *amazingly*
>>UNDEFINED.
> 
> from http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1680.pdf:
> 
>     ``Unfortunately, programming multithreaded applications of any
> kind in C++ remains a black art. Properties critical for reliable,
> efficient, and correct multithreaded execution are left unspecified.
> [...] many questions that programmers have about how to predict and
> control multithreaded code simply do not have answers. Superstition,
> myths, bad advice, and "hey, it worked for me" stories are rampant.''
> 
> this is due to the lack of a clearly specified shared memory model (a
> la java, until jsr-133) in the presence of multiple threads and
> instruction re-orderings due to compiler and processor
> "optimizations".

Although lack of a clearly specified shared memory model doesn't help,
I don't think that specifying such a model would solve the problems
that people typically encounter with using shared memory concurrency in
applications (especially large applications).

With or without a clearly specified model, it is not too difficult to
write applications that avoid low-level race hazards, and that therefore
have sequentially consistent behaviour under the intended semantics of
systems like POSIX or Java (even pre-JSR-133). But that isn't enough:
higher-level hazards from unintended interleavings are still possible,
and trying to use locks to avoid these presents too great a risk of
deadlock (for reasons explained in
<http://www.erights.org/talks/promises/paper/tgc05.pdf>).

Such a model would, however, have some use in languages and operating
systems that need to implement other models of concurrency in terms of
shared state.

-- 
David Hopwood <david.nospam.hopwood@REDACTED>