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
As is pointed out in
"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:
- The examples of compiler-introduced data races in the previously
cited PLDI paper deal mostly with cases in which a shared variable,
say x is already protected by a lock. Hence we would have to
require the programmer to declare lock-protected variables, i.e.
internal monitor variables, volatile. This was clearly never the
intention of the pthread standard. (See the discussion of
Memory Synchronization in SUSV3.)
More importantly, this turns out to be completely impractical. It is
very common to "wrap" single-threaded code in a lock to make it usable
in a multithreaded application. This would not be possible if all
variables/fields in the single-threaded code now had to be declared
Thread-safe versions of the C++ standard library, effectively
rely on this approach, which we believe to be the only viable one.
It is also similar to the one adopted by more recent Java container libraries,
Requiring volatile declarations for lock-protected
variables would effectively require most libraries to come
in two versions: A standard version, and one in which all internal static
variables were declared volatile.
- It is not hard to construct examples in which the compiler
introduces a race on a variable that should in fact be accessed by
only a single thread. (For one such example, see
WG14 paper N1131.) Thus we would also have to tell programmers
to declare unshared variables volatile, if it could look to
the compiler as though they might be shared. This appears to us to
be a completely unreasonable request.
- Aside from the preceding two issues, it is not at all clear that
volatile provides meaningful guarantees for multithreaded
programs, or what those are. Dave Butenhof has often been quoted
as stating that
"The use of "volatile" is not sufficient to ensure proper memory
visibility or synchronization between threads."
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++
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.