[cpp-threads] memory model

[Ben Hutchings]

Clark Nelson wrote:
> > I put a very rough draft describing my impression of the 
> > current state of
> > the memory model proposal at
> > 
> > http://www.hpl.hp.com/personal/Hans_Boehm/c++mm/mm.html
> 
> With respect to the memory model, I've been thinking about the terms of
> description that will eventually be used in the standard(s). The key
> passage is the "least requirements on a conforming implementation"
> (1.9p11). This is the formal statement of the as-if rule, and it also
> nails down (if that's the word) the semantics/requirements of volatile.
> The definition of "observable behavior" (1.9p6) is clearly relevant,
> even though it's not used.

Note, these are probably going to have to be changed somewhat.

> As far as I can tell, eventually some statement very much like the
> "least requirements" is going to have to be applied to each thread, and
> some definition quite like that of "observable behavior" is going to
> have to apply to the ways in which threads can interact.

I don't think it will be that similar.  In existing multithreaded memory
models, observability of one thread's memory operations by another
depends on both of them following proper protocol.

> This is the source of my discomfort with the idea of allowing threads to
> interact through non-volatile objects. Today, there are two classes of
> side effects: observable/external (to volatile objects) and
> "unobservable"/internal (all other). If we make all assignments
> observable, then what latitude is left for optimizers?
<snip>

No-one's advocating that.  The intent is that synchronisation and
ordering constraints will be recognised by the compiler and will
restrict optimisations by the compiler and by the hardware as necessary.
In the absence of such operations, optimisers will be almost as free as
they are present.

Ben.

-- 
Ben Hutchings
Horngren's Observation:
                   Among economists, the real world is often a special case.