Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.org!de-l.enfer-du-nord.net!feeder2.enfer-du-nord.net!newsfeed.straub-nv.de!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: Implicit memory barriers on x86
Date: Sat, 11 Jun 2011 22:26:04 +0200
Organization: ATMAN - ATM S.A.
Lines: 36
Message-ID: <it0j0b$d50$1@node2.news.atman.pl>
References: <071a9804-ceb8-4276-bfe2-7796359170ec@16g2000yqy.googlegroups.com> <9c31e82b-efad-4737-800c-921f623384f5@l18g2000yql.googlegroups.com> <4a5fbf57-3cb1-41da-8402-71eceeb0dcdc@z4g2000prk.googlegroups.com> <669c1812-ae75-4e54-bcba-9befb9d1a296@k16g2000yqm.googlegroups.com>
NNTP-Posting-Host: 213.241.90.232
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: node2.news.atman.pl 1307823947 13472 213.241.90.232 (11 Jun 2011 20:25:47 GMT)
X-Complaints-To: usenet@atman.pl
NNTP-Posting-Date: Sat, 11 Jun 2011 20:25:47 +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: <669c1812-ae75-4e54-bcba-9befb9d1a296@k16g2000yqm.googlegroups.com>
Xref: x330-a1.tempe.blueboxinc.net comp.programming.threads:261


> My "concern" about the non-locked write was the reads might break away
> from it due to "Intra-Processor Forwarding":
> bool flag = m_flag;
> unlock(); // forbids read re-order

How? Due to forwarding the read will move up(-to forwarded write), not
down.

>
> The guide is also explicit about this case (non-locked has release
> semantics):
> Example 8-2.  Stores Are Not Reordered with Older Loads
> Processor 0   Processor 1
> mov r1, [ _x]  mov r2, [ _y]
> mov [ _y], 1   mov [ _x], 1
> Initially x = y = 0. r1 = 1 and r2 = 1 is not allowed
> </guide>

Again, loads can be done way before writes; not the other way
round. Sounds like nice prefetching, and does not break the rules.

>
> I know that other architectures allow such read-write reordering
> though I'm not sure whether it actually makes them faster (e.g. stores
> are rare) and whether x86 has too much (windows) code at risk when
> relaxing this case (I heard that some x86 actually has control bit to
> allow read-write reordering).

Why this memory model - which seems quite strict
for me - helps anything? Why not leave everything to fences? Or is
it actually a part of implementation of fences (e.g. speculative loads
and their processing get discarded when fence is hit)?

Edek