[cpp-threads] seq_cst compare_exchange and store-load fencing

[Paul E. McKenney]

On Fri, Jan 02, 2009 at 10:10:07PM +0100, Alexander Terekhov wrote:
> On Fri, Jan 2, 2009 at 9:07 PM, Paul E. McKenney
> <paulmck at linux.vnet.ibm.com> wrote:
> [...]
> >> Formalities regarding distinguishing
> >>
> >> atomic_thread_fence(seq_cst), X.load(relaxed|acquire);
> >>
> >> vs.
> >>
> >> X.load(seq_cst);
> >>
> 
> Subsequent "aside for a moment..." phrase managed to escape here.
> Sorry, got interrupted. ;-)
> 
> >> why not state it in a more prominent place like 1.10 instead of 1K
> >> pages below it? ;-)
> >
> > Because you have to go 1K pages below it even to find out about the
> > memory_order enumeration.  ;-)
> 
> Note that 1.10 in N2800 versison already does mention both
> "sequentially consistent" and "sequential consistency".

Yeah, that is the English language for you...  For an adjective, one
would use "sequentially consistent", while for a noun, one would use
"sequential consistency".  This might be a case where identical wording
is more important than grammar, but I will leave that determination in
the able hands of our editor.

> >> > Now I personally have no objection to making seq_cst operations more
> >> > expensive, but others might.  ;-)
> >>
> >> I suspect that not making seq_cst operations more expensive (according
> >> to simple "fully-fenced" reasoning) will result in quite a lot of
> >> incorrect code.
> >>
> >> We'll see.
> >
> > Pretty simple rule: "If you want seq_cst operations to be guaranteed
> > ordered WRT non-seq_cst operations, use atomic_thread_fence(seq_cst)
> > to segregate the operations."
> 
> Okay, so why not add to C++ 1.10 (as in C++ 1.10 according to the
> N2800 version) additional paragraph 17:
> 
> "[/Note:/ Nothing requires that sequentially consistent operations
> [seq_cst, see 29.1] be ordered with respect to non-sequentially
> consistent operations [atomics as well, see 29.1] except as required
> by acquire, consume, and release semantics [see 29.1]. -- /end note/"

Works for me!  Of course, "seq_cst" would need to expand to
"memory_order_seq_cst" in the draft, but the abbreviation is nice in
email conversations.

> -and-
> 
> 18:
> 
> "[/Note:/ If you want sequentially consistent [seq_cst, see 29.1]
> results, use sequential consistency [seq_cst, see 29.1] everywhere.
> On the other hand, if you want to use optimizations involving
> non-sequentially consistent atomics [!seq_cst, see 29.1], make sure
> that you understand the actual guarantees that sequentially consistent
> [seq_cst, see 29.1] provide. -- /end note/]

For this last clause I would suggest substituting:

... make sure that you understand the actual guarantees provided by
your particular combination of sequentially consistent [seq_cst, see
29.1] and non-sequentially consistent [relaxed, acquire, consume, release,
and acq_rel, see 29.1] operations. -- /end note/]

> -and-
> 
> 19:
> 
> "[/Note:/ If you want sequentially consistent [seq_cst, see 29.1]
> operations to be guaranteed ordered WRT non-seq_cst operations
> [!seq_cst, see 29.1], use atomic_thread_fence(seq_cst) [see 29.6] to
> segregate the operations. -- /end note/"
> 
> :-)

Works for me!

						Thanx, Paul