Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!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:25:58 +0200
Organization: A noiseless patient Spider
Lines: 59
Message-ID: <4DFA2086.5791E46@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>
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="19625"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+S0RTrg5MN5EhI39WiGf8wkf52hCOPJjU="
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
Cancel-Lock: sha1:0jBz02qcUgYyFOvw9NOCF+ch72Y=
Xref: x330-a1.tempe.blueboxinc.net comp.programming.threads:301

Addition re "Incorrect implementation" below:

Alexander Terekhov wrote:
> 
> 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?
> 
> In
> 
>   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
> 
> Implementation 1:
> 
>   Load Seq_Cst:  LOCK XADD(0)
>   Store Seq_Cst: LOCK XCHG
> 
> Implementation 2:
> 
>   Load Seq_Cst:  LOCK XADD(0)
>   Store Seq_Cst: MOV, MFENCE
> 
> Implementation 3:
> 
>   Load Seq_Cst:  MFENCE, MOV
>   Store Seq_Cst: LOCK XCHG
> 
> Incorrect implementation
> 
>   Load Seq_Cst:  MFENCE, MOV
>   Store Seq_Cst: MOV, MFENCE
> 
> is busted because IRIW won't work.

That is my thinking... but according to 

http://portal.acm.org/citation.cfm?id=1926394

the "Incorrect implementation" above is actually correct (probably
because according to them, MFENCE has the same semantics as PPC's
hwsync).

(I'm personally still in doubt).

regards,
alexander.