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 12:05:53 +0200
Organization: A noiseless patient Spider
Lines: 25
Message-ID: <4DF9D581.E607BEB4@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>
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="24206"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+Pwg3X7E3kh2PNP7NOM6Wqj0QDhiShYKo="
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
Cancel-Lock: sha1:nLvOodbvmGBkgKccgO6qg+gp3AU=
Xref: x330-a1.tempe.blueboxinc.net comp.programming.threads:290


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...

regards,
alexander.