Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming.threads > #248

Re: Implicit memory barriers on x86

Show all headers | View raw

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

Back to comp.programming.threads | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Implicit memory barriers on x86 Rani Sharoni <ranisharoni75@gmail.com> - 2011-06-07 13:47 -0700
  Re: Implicit memory barriers on x86 David Schwartz <davids@webmaster.com> - 2011-06-08 10:11 -0700
    Re: Implicit memory barriers on x86 Rani Sharoni <ranisharoni75@gmail.com> - 2011-06-08 12:53 -0700
  Re: Implicit memory barriers on x86 Edek <edek.pienkowski@gmail.com> - 2011-06-08 20:29 +0200
    Re: Implicit memory barriers on x86 Rani Sharoni <ranisharoni75@gmail.com> - 2011-06-08 12:48 -0700
      Re: Implicit memory barriers on x86 Edek <edek.pienkowski@gmail.com> - 2011-06-08 23:41 +0200
        Re: Implicit memory barriers on x86 Rani Sharoni <ranisharoni75@gmail.com> - 2011-06-08 22:19 -0700
        Re: Implicit memory barriers on x86 David Schwartz <davids@webmaster.com> - 2011-06-09 16:25 -0700
  Re: Implicit memory barriers on x86 Rani Sharoni <ranisharoni75@gmail.com> - 2011-06-10 14:19 -0700
    Re: Implicit memory barriers on x86 David Schwartz <davids@webmaster.com> - 2011-06-11 02:57 -0700
      Re: Implicit memory barriers on x86 Rani Sharoni <ranisharoni75@gmail.com> - 2011-06-11 09:21 -0700
        Re: Implicit memory barriers on x86 Edek <edek.pienkowski@gmail.com> - 2011-06-11 22:26 +0200
    Re: Implicit memory barriers on x86 Alexander Terekhov <terekhov@web.de> - 2011-06-11 12:31 +0200
      Re: Implicit memory barriers on x86 "Chris M. Thomasson" <cristom@charter.net> - 2011-06-13 09:51 -0700
    Re: Implicit memory barriers on x86 Rani Sharoni <ranisharoni75@gmail.com> - 2011-06-11 12:30 -0700
      Re: Implicit memory barriers on x86 Edek <edek.pienkowski@gmail.com> - 2011-06-11 22:18 +0200
        Re: Implicit memory barriers on x86 Rani Sharoni <ranisharoni75@gmail.com> - 2011-06-11 13:31 -0700

csiph-web