[cpp-threads] Brief example ITANIUM Implementation for C/C++MemoryModel

[Paul E. McKenney]

On Fri, Jan 02, 2009 at 06:50:00PM +0100, Alexander Terekhov wrote:
> On Fri, Jan 2, 2009 at 5:39 PM, Peter Dimov <pdimov at mmltd.net> wrote:
> > Alexander Terekhov:
> >
> >> That would be the case if C/C++ would offer only seq_cst atomic
> >> operations without any relaxed ones (I mean release/acquire/relaxed).
> >> But that is not the case under the current draft. So my interpretation
> >> is based on simple reasoning: seq_cst means fully-fenced (with
> >> redundant fencing being eligible for removal by optimizers).
> >
> > I don't think that it does. The C++MM (if my understanding is correct)
> > doesn't prohibit load-relaxed (or an ordinary load) sinking below
> > load-seq-cst.
> 
> IOW,
> 
> P1: Y.store(1, seq_cst);
> P2: Z.store(1, seq_cst); a = Y.load(relaxed);
> P3: b = Y.load(relaxed); fence(seq_cst); c = Z.load(relaxed);

P2's Z.store() has only release semantics, so is not required to
order against subsequent non-seq_cst operations.

> may legitimately yield a=0, b=1, c=0 just like in case of
> 
> P1: Y.store(1, seq_cst);
> P2: Z.store(1, seq_cst); a = Y.load(relaxed);
> P3: b = Y.load(relaxed); c = Z.load(seq_cst);

And this one adds the fact that P3's Z.load() has only acquire
semantics, so is not required to order against prior non-seq_cst
operations.

> with both examples above actually meaning
> 
> P1: Y.store(1, seq_cst);
> P2: Z.store(1, seq_cst); a = Y.load(relaxed);
> P3: b = Y.load(relaxed); c = Z.load(relaxed);

This has the same semantics as your second example above, but loses
your first example's ordering of P3's two loads.  Of course, your
example doesn't happen to be sensitive to the order of these two loads,
so in this broader sense I guess it could be thought of as equivalent
to your first example as well.

> right? WOW.
> 
> You'll have a hard time explaining this... ;-)

My explanation is: "If you want sequentially consistent results, use
memory_order_seq_cst everywhere".  On the other hand, if you want to use
optimizations involving non-seq_cst atomics, make sure that you
understand the actual guarantees that they provide.  ;-)

							Thanx, Paul