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 13:57:14 +0200
Organization: A noiseless patient Spider
Lines: 68
Message-ID: <4DF9EF9A.911CC74F@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>
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="719"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/X8jXBNzmrd3U4+LptercuyjG7SODfOtc="
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
Cancel-Lock: sha1:I72S3v6QyowoylLACp6NvZboWHY=
Xref: x330-a1.tempe.blueboxinc.net comp.programming.threads:292


Anthony Williams wrote:
> 
> Alexander Terekhov <terekhov@web.de> writes:
> 
> > Anthony Williams wrote:
> >>
> >> Edek <edek.pienkowski@gmail.com> writes:
> >>
> >> > As a side note, I compiled all ops on x86_64, and atomic<int>::load
> >> > is mfence/load/mfence even for relaxed. I'd need some time to analyse
> >> > the thing from perspective of other ops implementations in all
> >> > orderings, and this leads me to the not so subtle question:
> >>
> >> Ouch. That is a seriously over-cautious implementation. Atomics should
> >> not need any fences on x86_64 unless you actually write
> >> atomic_thread_fence(memory_order_seq_cst)
> >>
> >> See my blog entry for the required operations:
> >>
> >> http://www.justsoftwaresolutions.co.uk/threading/intel-memory-ordering-and-c++-memory-model.html
> >>
> >> The only one that is not a plain MOV is a seq_cst store, which is an
> >> XCHG.
> >
> > I believe that a seq_cst load is not a plain move either...
> 
> Why do think it shouldn't be, 

Akin to what Jeffrey Yasskin said on your blog:

http://www.justsoftwaresolutions.co.uk/threading/intel-memory-ordering-and-c++-memory-model.html

"Do you happen to have a link to a proof that a plain mov is all that's
needed for a sequentially-consistent load? I see from the memory model
documents that the xchg'es all happen in a total order, and that movs
won't be reordered across xchg, but I'm having trouble getting from
there to sequential consistency.

by Jeffrey Yasskin at 07:23:51 on Wednesday, 19 May 2010"

Do *you* happen to have a link to a proof?

> and what do you think it should be instead?

http://www.decadent.org.uk/pipermail/cpp-threads/2008-December/001933.html

"Load Seq_Cst:  LOCK XADD(0) // alternative: MFENCE,MOV (from memory)"

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

"Sequentially consistent atomics 

The proposal above includes two implementations of sequentially
consistent atomic reads and writes; one with the x86 locked
instructions, and the other with fence instructions on both the reads
and writes. However, we can prove that it suffices either to place an
mfence before every sc read, or after every sc write, but that it is not
necessary to do both. In practice, placing the fence after the sc writes
is expected to yield higher performance."

> 
> The mapping in my blog post was confirmed by Intel processor engineers.

Without a proof?

regards,
alexander.