Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!goblin2!goblin.stu.neva.ru!plix.pl!newsfeed1.plix.pl!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: Wed, 08 Jun 2011 20:29:35 +0200
Organization: ATMAN - ATM S.A.
Lines: 69
Message-ID: <isof2a$ck2$1@node2.news.atman.pl>
References: <071a9804-ceb8-4276-bfe2-7796359170ec@16g2000yqy.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 1307557770 12930 213.241.90.232 (8 Jun 2011 18:29:30 GMT)
X-Complaints-To: usenet@atman.pl
NNTP-Posting-Date: Wed, 8 Jun 2011 18:29:30 +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: <071a9804-ceb8-4276-bfe2-7796359170ec@16g2000yqy.googlegroups.com>
Xref: x330-a1.tempe.blueboxinc.net comp.programming.threads:248

On 06/07/2011 10:47 PM, Rani Sharoni wrote:
> Hi,
>
> The Intel x86/x64 reference guide (8.2.2) states the following:
> A) Reads are not reordered with other reads.

Please quote.

> B) Writes are not reordered with older reads.

Please quote.

> C) Writes to memory are not reordered with other writes

Please quote.

> D) Reads may be reordered with older writes to different locations but
> not with older writes to the same location.
>

When reads refer to the same location as a previous write, they will 
usually not be read at all, if the write was just before.
They result will be that they will be executed just as if being read
usually before the write actually would take place...


> Based on the above, will the following act as full memory barrier
> (prevent reordering):
> mov [esp], eax   #1 write
> mov eax, [esp]   #2 read

...like here.

>
> Seems like based on the above rules:
> 1) #1 and #2 - no reorder per (D)
> 2) old reads - no reorder with #2 per (A)
> 3) old writes - no reorder with #1 per (C)
> 4) new reads - no reorder with #2 per (A)
> 5) new writes - no reorder with #1 and #2 per (C) and (B)
>
> Can the above act like the 'mfence' instruction?

That would be impressive.

> I must be wrong about something here or otherwise x86 reordering is
> quite limited...
> I also heard that mfence is somewhat expensive (compared with not
> having it).

Certainly more expensive than not having it in terms of execution time.
Like most CPU instructions BTW, maybe some NOPs here and there actually
do speed things up.

When someone says it is expensive, it is usually meant that
if atomicity is required, and a memory barrier semantics isn't, an
atomic might be the right tool.

>
> Will (B) and (C) allow something like spinlock release to be
> implemented using simple (non locked) write on x86?
> I think that I saw some article that mentioned this.

Maybe. I mean maybe you saw such an article ;)

>
> Thanks,
> Rani