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


Groups > comp.programming.threads > #261

Re: Implicit memory barriers on x86

From Edek <edek.pienkowski@gmail.com>
Newsgroups comp.programming.threads
Subject Re: Implicit memory barriers on x86
Date 2011-06-11 22:26 +0200
Organization ATMAN - ATM S.A.
Message-ID <it0j0b$d50$1@node2.news.atman.pl> (permalink)
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>

Show all headers | View raw


> 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

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