Meyer, OO and concurrency
Wed Jul 20 01:47:10 CEST 2005
Taj Khattra wrote:
> On 7/14/05, Joe Armstrong (AL/EAB) <> 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*
> 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
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
Such a model would, however, have some use in languages and operating
systems that need to implement other models of concurrency in terms of
David Hopwood <>
More information about the erlang-questions