{ edited by mod to wrap long lines at ~70 characters.  -mod }

[Part 1]
E.g.,

atomic x;
atomic y;
atomic z;
// memory_order_seq_cst by default
x.store(1);  //1
y.store(2);  //2
z.load();    //3

(1) Does the program order of 1-2-3 have to be respected for these
sequentially consistent atomic operations? To me, it's a positive
answer intuitively, but I just can't prove it by find anything
related in the Standard.

(2) Is there any part in the language standard specifying this rule?

[Part 2]
(3) What's the difference between
"x.store(1, memory_order_seq_cst);" and
"x.store(1, memory_order_release);" ?

E.g.,
x.store(1, memory_order_release); //4
y.load(memory_order_acquire);     //5

x.store(1, memory_order_seq_cst); //6
y.load(memory_order_acquire);     //7

Instructions 4 and 5 can be reordered. But what about 6 and 7?
(4) Can instruction 6 and 7 above be reordered generally?

[Part 3]
(5) Does the standard require a full memory barrier semantics for
atomic_thread_fence(memory_order_seq_cst)? 

(6) What about x.store(1, memory_order_seq_cst)? Does it also have
the full memory barrier emitted?

Thanks!

Best regards,
Eric


-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

On Wed, 27 Aug 2014 07:46:24 CST
Eric Z  wrote:
> On Tuesday, August 26, 2014 1:40:08 PM UTC+8, Chris Vine wrote:
> > On Mon, 25 Aug 2014 10:18:38 CST
[snip]
> > The question of inter-thread ordering between these atomic
> > operations
> > 
> > is meaningless here, as they are carried out on different atomic
> > 
> > variables: in particular your load is in respect of a different
> > atomic
> > 
> > variable from your two stores, so there is no synchronization by
> > 
> > reference to which sequential consistency can be relevant.  But
> > there
> > 
> > doesn't need to be because they all seem to be done in the same
> > thread,
> > 
> > so normal C++ sequencing rules apply.
> > 
> Thanks. I agree w/ you that 1, 2, 3 have a sequenced-before relation
> such that 1 < 2 < 3 ("<" means happens-before). But that's just
> a relation with respect to the single thread. Other threads may seem
> a different order of these three instruction. So what I'm asking is
> the impact of sequential consistency of these instructions with regard
> to other threads. Whether it enforces the same total order 1 < 2 < 3
> which is perceived by all threads?
> 
> There must be some total order, that's no doubt, because that's what
> sequential consistency means. What I'm wondering is whether the order
> 1 < 2 < 3 is kept in this total order S? i.e., if A is
> sequenced-before B, does it mean that A must happen-before B in the
> total order S? I remember that I saw Anthony Williams mentioned it in
> the threading group. But I'm not sure if there is a formal definition
> of the language, or he was wrong.
> 
> Now you know my question. Thanks for the link btw. I've been going
> through lots of materials on the Web, including that one already.
> 
> And do you have any answers for the other parts of my questions, by
> the way?

I have pointed out that there is no synchronization in the code
examples you provided which could attract sequential consistency, or
acquire/release semantics for that matter, as all your loads were made
with respect to different atomic variables from your stores.  There is
nothing more that can be said in answer to your questions.

Chris



-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

{ quoted server banner redacted. -mod }

On Thursday, August 28, 2014 9:20:03 PM UTC+8, Chris Vine wrote:
> On Wed, 27 Aug 2014 07:46:24 CST
> 
> Eric Z  wrote:
> 
> > On Tuesday, August 26, 2014 1:40:08 PM UTC+8, Chris Vine wrote:
> 
> > > On Mon, 25 Aug 2014 10:18:38 CST
> 
> [snip]
> 
> > > The question of inter-thread ordering between these atomic
> 
> > > operations
> 
> > > 
> 
> > > is meaningless here, as they are carried out on different atomic
> 
> > > 
> 
> > > variables: in particular your load is in respect of a different
> 
> > > atomic
> 
> > > 
> 
> > > variable from your two stores, so there is no synchronization by
> 
> > > 
> 
> > > reference to which sequential consistency can be relevant.  But
> 
> > > there
> 
> > > 
> 
> > > doesn't need to be because they all seem to be done in the same
> 
> > > thread,
> 
> > > 
> 
> > > so normal C++ sequencing rules apply.
> 
> > > 
> 
> > Thanks. I agree w/ you that 1, 2, 3 have a sequenced-before relation
> 
> > such that 1 < 2 < 3 ("<" means happens-before). But that's just
> 
> > a relation with respect to the single thread. Other threads may seem
> 
> > a different order of these three instruction. So what I'm asking is
> 
> > the impact of sequential consistency of these instructions with regard
> 
> > to other threads. Whether it enforces the same total order 1 < 2 < 3
> 
> > which is perceived by all threads?
> 
> > 
> 
> > There must be some total order, that's no doubt, because that's what
> 
> > sequential consistency means. What I'm wondering is whether the order
> 
> > 1 < 2 < 3 is kept in this total order S? i.e., if A is
> 
> > sequenced-before B, does it mean that A must happen-before B in the
> 
> > total order S? I remember that I saw Anthony Williams mentioned it in
> 
> > the threading group. But I'm not sure if there is a formal definition
> 
> > of the language, or he was wrong.
> 
> > 
> 
> > Now you know my question. Thanks for the link btw. I've been going
> 
> > through lots of materials on the Web, including that one already.
> 
> > 
> 
> > And do you have any answers for the other parts of my questions, by
> 
> > the way?
> 
> 
> 
> I have pointed out that there is no synchronization in the code
> 
> examples you provided which could attract sequential consistency, or
> 
> acquire/release semantics for that matter, as all your loads were made
> 
> with respect to different atomic variables from your stores.  There is
> 
> nothing more that can be said in answer to your questions.
> 
> 
> 
> Chris
> 

"there is no synchronization in the code examples you provided which
could attract sequential consistency.."
You are completely wrong.

Here is it again:
atomic x;
atomic y;
atomic z;
// memory_order_seq_cst by default
x.store(1);  //1
y.store(2);  //2
z.load();    //3 

All stores and loads here are sequentially consistent. And who tells
you that there is NO synchornization among sequentially consistent
atomic operations anyway?

Best regards,
Eric


-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]