Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail
From: Alexander Terekhov <terekhov@web.de>
Newsgroups: comp.programming.threads
Subject: Re: questions about memory_order_seq_cst fence
Date: Thu, 16 Jun 2011 17:37:38 +0200
Organization: A noiseless patient Spider
Lines: 60
Message-ID: <4DFA2342.52931D8@web.de>
References: <43eb372b-6517-4914-b647-860f1f7136ba@k15g2000pri.googlegroups.com> <it5sht$i7j$1@node2.news.atman.pl> <b7657dae-d49f-4859-8020-b5d76bfae2cd@p9g2000prh.googlegroups.com> <itbb7k$uhh$1@node2.news.atman.pl> <87boxyfctc.fsf@justsoftwaresolutions.co.uk> <4DF9D581.E607BEB4@web.de> <8739jaf59n.fsf@justsoftwaresolutions.co.uk> <4DF9EF9A.911CC74F@web.de> <87wrgm9bxk.fsf@justsoftwaresolutions.co.uk> <4DFA18D0.3A413EED@web.de> <87oc1xajr3.fsf@justsoftwaresolutions.co.uk>
Reply-To: terekhov@web.de
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Injection-Info: mx04.eternal-september.org; posting-host="MCbSEzW5qwGLFMNXJh39IQ"; logging-data="25419"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/n7Vb0K1DAquGhyAOuXij+9mEHoU7/Dc0="
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
Cancel-Lock: sha1:dVtlnZ8cqml4YoPX2Ub+gf76Zog=
Xref: x330-a1.tempe.blueboxinc.net comp.programming.threads:302


Anthony Williams wrote:
> 
> Alexander Terekhov <terekhov@web.de> writes:
> 
> > Anthony Williams wrote:
> > [...]
> >> LOCKed instructions have a total order (7.2.3.8 in my copy of the Intel
> >> 64 and IA-32 SDM Vol 3A), so if you use XCHG for stores (as per my blog
> >> post) then all processors/threads must agree on the order of the writes.
> >>
> >> This is the key to SC --- all SC stores must have a single total order
> >> which is agreed across all threads.
> >>
> >> Why do you think this is not enough?
> >
> >   x.store(44, memory_order_relaxed); // or _release
> >   r1 = y.load(memory_order_seq_cst);
> >
> > there should be a store-load reordering constraint, just like in
> >
> >   x.store(44, memory_order_seq_cst);
> >   r1 = y.load(memory_order_relaxed); // or _acquire/_consume
> 
> Why? 

Because the above is the same as

  x.store(44, memory_order_relaxed); // or _release
  atomic_thread_fence(memory_order_seq_cst); 
  r1 = y.load(memory_order_relaxed); // or _acquire/_consume

> Can you give an example that would be broken by the lack of such a
> constraint, 

Any code written with the expectation that 

  x.store(44, memory_order_relaxed); // or _release
  r1 = y.load(memory_order_seq_cst);

and/or 

  x.store(44, memory_order_seq_cst);
  r1 = y.load(memory_order_relaxed); // or _acquire/_consume

is the same as

  x.store(44, memory_order_relaxed); // or _release
  atomic_thread_fence(memory_order_seq_cst); 
  r1 = y.load(memory_order_relaxed); // or _acquire/_consume

> and a reference to the FDIS that guarantees the presence of
> that constraint?

Do you have a reference to FDIS? (*&%*(&^$%&*(^_*(&+)(&*)&^978

http://groups.google.com/groups?threadm=4DF1EC53.29714FE9@web.de

regards,
alexander.