Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.org!de-l.enfer-du-nord.net!feeder1.enfer-du-nord.net!feeder.erje.net!news-2.dfn.de!news.dfn.de!news.uni-stuttgart.de!news.nask.pl!news.nask.org.pl!newsfeed2.atman.pl!newsfeed.atman.pl!.POSTED!not-for-mail
From: Edek <edek.pienkowski@gmail.com>
Newsgroups: comp.programming.threads
Subject: Re: questions about memory_order_seq_cst fence
Date: Thu, 16 Jun 2011 14:39:59 +0200
Organization: ATMAN - ATM S.A.
Lines: 54
Message-ID: <itcti5$ddh$1@node2.news.atman.pl>
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>
NNTP-Posting-Host: tarket-cp.krakow.sint.pl
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: node2.news.atman.pl 1308227973 13745 213.241.90.249 (16 Jun 2011 12:39:33 GMT)
X-Complaints-To: usenet@atman.pl
NNTP-Posting-Date: Thu, 16 Jun 2011 12:39:33 +0000 (UTC)
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Linux/3.1.0-15 Thunderbird/3.1.0
In-Reply-To: <87boxyfctc.fsf@justsoftwaresolutions.co.uk>
Xref: x330-a1.tempe.blueboxinc.net comp.programming.threads:296

On 06/16/2011 09:35 AM, 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.
>
> Anthony

 From Joshua Maurice:
>> PS.
>> > As a side note, I compiled all ops on x86_64, and atomic<int>::load
>> > is mfence/load/mfence even for relaxed.
> This is very wrong. At least, very counter to intent. What
> implementation of C++0x threading are you using? Maybe it's a first
> attempt implementation, and they're going to "fix" it later?
>

Answering this:

it is certainly possible that this is a 'quick-and-dirty'
implementation. I wouldn't care now, given the status is experimental,
if it gives worse performance [1]. I am not fit to argue,
but maybe there are technical details why currently in this compiler
it is necessary [3].

I do care whether it is correct, and correct me if I'm wrong, there is
nothing wrong with stricter ordering than asked for [2], and looser
language lawyering done by the compiler at the moment.

Edek


[1] Performance: In all cases? In some cases, and not in others?

[2] Unless someone tries to say 'I had a proof: my algorithm did not
fail on compilers X and Y on platforms A,B,C. My proof was wrong,
because the compiler implemented a more strict ordering, and this
caused me to think my algorithm was right when it was not'

[3] what comes to my mind: missing alignment requirements, or something
of this kind, in the current state of the compiler.