C++ memory model

[Peter A. Buhr]

More thundering silence to my last email, but no one has threatened to kick me
off the team, so I'll continue to ramble on coherently.

How to build a memory model for C++? This is a difficult question because C++
has no concurrency. Bjarne specifically punted on this issue:

  My conclusion at the time when I designed C++ was that no single model of
  concurrency would serve more than a small fraction of the user community
  well.  I could build a single model of concurrency into C++ by providing
  language features that directly supported its fundamental concepts and ease
  its use through notational conveniences.  However, if I did that I would
  favor a small fraction of my users over the majority.  This I declined to do,
  and by refraining from doing so I left every form of concurrency equally
  badly supported by the basic C++ mechanisms.  [Stroustrup96]

As a result, we have nothing to leverage as the Java people did with their
memory model. In the Java memory model, the most important first step was to
make the thread and monitor objects work because that is the domain where most
concurrent programs are written. After that, any additional extensions to the
memory model were to support a handful of other concurrent idioms, like
double-check, Dekker's algorithm, etc. (I know I'm going to be corrected on
this. ;-)

We could look at what is done in C, e.g., pthreads, but that does not speak to
the huge difference between these two languages. What makes sense and works
well for C, does not necessarily carry over to C++. Yes, technically any C
approach can work in C++ because C++ is mostly a superset of C. But a C
approach is never going to capture the C++ style or integrate with its many
high-level features.

We could build a memory model that supports everything that is concurrent, but
the problem with this approach is that it will have a significant affect on
code optimization.

So how can we build a concurrent memory model for a concurrency system that does
not exist? If we had some ham, we could have ham and eggs, if we had some eggs.

To build a memory model, we have to first lay down some idea of what the
concurrency system is going to look like and then we can show how the memory
model handles this system. If we want to handle everything, then we have to be
ready to swallow the bitter pill of losing most code optimization (and I'm not
sure it can be done anyway). If we only want to handle somethings, then we have
to define what those somethings are, and be prepared for criticism because we
don't handle everything. Maybe I'm being too pessimistic, and if so, please
show me the magic solution.

So I'm claiming that you can't build a memory model in isolation. First, you
have to construct a list of what concurrency features/facilities you want to
provide, and second, the memory model has to be developed to accommodate these
features/facilities. The list of concurrency features/facilities can be based
on de facto concurrency systems, but I'm very afraid of a kitchen sink solution
being the greatest common multiple of all these systems.

If I'm right (and I could be totally wrong), it seems our first step is to
start from nothing because there is nothing, and make a list of what
concurrency features/facilities C++ needs to support, how these might be
represented in the language, and then develop a memory model that encompasses
these features/facilities. Am I barking up the wrong tree, or does someone
agree with me? Or has all this been said already, and I'm just coming into the
discussion late?


[Stroustrup96] Bjarne Stroustrup.  A Perspective on Concurrency in C++.  In
Gregory V. Wilson and Paul Lu, editors, "Parallel Programming in C++",
Scientific and Engineering Computation Series, pages xxvi-xxvii. MIT Press,
1996.