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

Groups > comp.programming.threads > #260

Re: Implicit memory barriers on x86

Show all headers | View raw

On 06/11/2011 09:30 PM, Rani Sharoni wrote:
>> The Intel guide proves me *wrong* since the ordering rules are
>> not as straight forward as I thought.
>
> Quiz:
> Processor 0 Processor 1
>                    mov [ _y], 1
> mov [ _x], 1 mov r1, [ _y]
> mov [ _y], 1 mov r2, [ _x]
>
> Initially x = y = 0.
> Quiz: r1 = 1 and r2 = 0 is not allowed???

Is allowed.

I would rather see that on p1: _y (r1) differs from p0 _y.

That does not break threading stuff, on processor 1 the
difference is between

a)

1 -> _y
release_spinlock()
r1 <- _y

and

b)

1 -> _y
r1 <- _y
release_spinlock()

In general, if release_spinlock would be a "black box" with
possible mfence semantics, this would break stuff. (r1 could
have wrong value).

But AFAIK release_lock only prevents writes from moving down, not
reads moving up; if you're implementing a simple lock, that is
basic stuff; am I missing something?

>
> You can see the above inconsistency when combining the following:
> 1)  Stores Are Not Reordered with Other Stores - no allowing the above
> 2)  Intra-Processor Forwarding is Allowed          - allowing the
> above
>
> 1) Example 8-1.  Stores Are Not Reordered with Other Stores
> Processor 0 Processor 1
> mov [ _x], 1 mov r1, [ _y]
> mov [ _y], 1 mov r2, [ _x]
> Initially x = y = 0. r1 = 1 and r2 = 0 is not allowed
>
> 2) Example 8-5.  Intra-Processor Forwarding is Allowed
> Processor 0 Processor 1
> mov [ _x], 1 mov [ _y], 1
> mov r1, [ _x] mov r3, [ _y]
> mov r2, [ _y] mov r4, [ _x]
> Initially x = y = 0. r2 = 0 and r4 = 0 is allowed
>
> Rani

The semantics is clever: there are two aspects of it, one is what
the virtual processor does, and abother is how the actions are visible
to other virtual processors and how others processor's action are
visible to it.

I would note that the name of the memory model includes the forwarding
in its name in the manual.

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