cation does not meet its desired intent
of having certain common optimizing
transformations preserve program
meaning. Second, its inherent complexity and the new observations make
it difficult to prove the correctness of
any real system. Third, the specification
methodology is inherently fragile—
small changes usually result in hard-to-detect unintended consequences.
The Java model was largely guided
by an emergent set of test cases, 33 based
on informal code transformations that
were or were not deemed desirable.
While it may be possible to fix the Java
model, it seems undesirable that our
specification of multithreaded program
behavior would rest on such a complex
and fragile foundation. Instead, the section entitled “Implications for Languages” advocates a fundamental rethinking
of our approach.
The C++ memory model. The situation in C++ was significantly different
from Java. The language itself provided
no support for threads. Nonetheless,
they were already in widespread use,
typically with the addition of a library-based threads implementation, such as
pthreads22 or the corresponding Microsoft Windows facilities. Unfortunately
the relevant specifications, for example
the combination of the C or C++ standard with the Posix standard, left significant uncertainties about the rules
governing shared variables. 9 This made
it unclear to compiler writers precisely
what they needed to implement, resulted in very occasional failures for which
it was difficult to assign blame to any
specific piece of the implementation
and, most importantly, made it difficult
to teach parallel programming since
even the experts were unable to agree on
some of the basic rules, such as whether
Figure 4(a) constitutes a data race. (
Correct answer: No.)
Motivated by these observations,
we began an effort in 2005 to develop
a proper memory model for C++. The
resulting effort eventually expanded to
include the definition of atomic (
synchronization, analogous to Java volatile) operations, and the threads API
itself. It is part of the current Committee Draft24 for the next C++ revision. The
next C standard is expected to contain
a very similar memory model, with very
similar atomic operations.
This development took place in the
face of increasing doubt that a Java-like
memory model relying on sequential
consistency for data-race-free programs
was efficiently implementable on main-
stream architectures, at least given the
specifications available at the time.
Largely as a result, much of the early dis-
cussion focused on the tension between
the following two observations, both of
which we still believe to be correct given
existing hardware:
