A Memory Model for C++: FAQ

This is an attempt to summarize the responses to common questions/objections to out work on threads in C++ that in our opinion do have clear-cut responses. We're still working on some of the harder questions ...

Why is this being addressed as a C++ issue instead of a Posix/thread library issue?

As is pointed out in H. Boehm, "Threads Cannot Be Implemented As a Library", PLDI 2005 or the technical report version, the fundamental difficulty with the current C++/pthreads approach to threading is that a C++ compiler can introduce data races where there were none in the source. This is fundamentally a language specification and compiler issue, and cannot be addressed by changes in the threads library specification.

Why is this being addressed as a C++ instead of C issue?

Historically the reason was that some of us had better connections to the C++ committee. At this point, a better reason is that the C++ committee is actively working on a revised language specification, but the C committee is not. We are trying to keep the C committee well-informed, and are hoping that they will eventually adopt some of the C++ changes, possibly as a technical report instead of a full standard revision.

Why cannot the compiler optimization issues just be side-stepped by declaring the relevant shared variables volatile?

This turns out to be impractical, for several reasons:

Why is it not possible to just adopt the Java memory model?

The Java memory model was heavily motivated by the desire to preserve both type-safety and some other security guarantees, both of which are essential if untrusted code is to be run in the same address space with trusted code. Since this is in any case impossible for ordinary C or C++ code, this is no longer a consideration.

Furthermore, it appears that making Java-like guarantees for C++ is potentially expensive, particularly on architectures that provide a weak memory model, or weak atomicity guarantees for ordinary stores. For example, implementations would have to ensure that an object pointer cannot be passed from one thread to another without previously making the objects vtable pointer visible to the other thread. This is likely to require a memory barrier during object construction. And C++ programmers, unlike Java programmers, tend to expect object construction to be a very light-weight operation.

It does however appear more and more likely that we will borrow heavily from the Java memory model, particularly to explain the semantics of C++ atomic operations.

Why is it not possible to just adopt the CLI memory model?

See the answer to the preceding question. The CLI memory model also still appears to be a moving target.