C++ memory model

[Herb Sutter]

Quick ack again: I'm interested but I'll be unresponsive for the next
two months because I've now entered my spring travel madness. I'll see
some of you in Lillehammer in April, and I'll be more responsive again
starting around May.

Thanks Peter,

Herb


> -----Original Message-----
> From: Peter A. Buhr [mailto:pabuhr at plg.uwaterloo.ca]
> Sent: Tuesday, February 22, 2005 2:17 PM
> To: Herb Sutter; hans.boehm at hp.com; ben at decadentplace.org.uk;
> kevlin at curbralan.com; andrei at metalanguage.com; magedm at us.ibm.com;
> pugh at cs.umd.edu; rcbilson at uwaterloo.ca; dl at cs.oswego.edu;
> asharji at plg.uwaterloo.ca
> Subject: C++ memory model
> 
> 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.