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

[Paul E. McKenney]

On Fri, Jan 02, 2009 at 08:53:01PM +0100, Alexander Terekhov wrote:
> On Fri, Jan 2, 2009 at 7:28 PM, Paul E. McKenney
> <paulmck at linux.vnet.ibm.com> wrote:
> 
> [... reasoning ...]
> 
> > 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.  ;-)
> 
> I suggest to add this further explanation of your as a note to the
> prominent place like 1.10 just like your previous note:
> 
> "[Nothing] requires that seq_cst operations be ordered with respect to
> non-seq_cst operations [atomics as well, see 29.1] except as required
> by acquire, consume, and release semantics."

Sounds good to me!

> Now, what is your reasoning regarding
> 
> P1: Y.store(1, relaxed);
> P2: Z.store(1, relaxed); fence(seq_cst); a = Y.load(relaxed);
> P3: b = Y.load(relaxed); fence(seq_cst); c = Z.load(relaxed);
> 
> and a=0, b=1, c=0 outcome?

P1's and P2's stores are relaxed, and therefore are not guaranteed to be
seen in the same order by all threads.  So it is perfectly legal for P2
to think that Z.store() happened first and for P3 to think that Y.store()
happened first.

							Thanx, Paul