Opaque: coherence partial order.

--===============8654411808761513226==
Content-Type: multipart/alternative; boundary="0000000000009b502a05c9a6a13f"

--0000000000009b502a05c9a6a13f
Content-Type: text/plain; charset="UTF-8"

Hi,

One of the many definitions of coherence is the following:
1) a total order of all loads/stores per address.
2) a load needs to see the most recent store before it in the coherence
order.
3) the coherence order should be compatible with the (preserved) program
order of each thread.

There are important relaxations:

1) The actual order of loads and stores isn't relevant, it is all about
keeping up appearances. So in theory the above requirements can be
violated, as long as nobody can prove it happened. This goes for many other
memory models like sequential consistency or TSO.

2) Coherence order doesn't imply any real time guarantees, reads and writes
can be skewed similar as with sequential consistency. So a read doesn't
need to see the most recent write before it in physical clock terms; it
just needs to return the most recent write before it in the coherence order.

What i understand from the  information about opaque:
http://gee.cs.oswego.edu/dl/html/j9mm.html
is that opaque doesn't provide a total order on a single address. So its
usage of coherence is slightly different from the general notion of
coherence.

Given the fact that coherence to some extent is quite relaxed, what is the
reason that it wasn't specified in terms of a total order? Is it possible,
in theory, to observe a violation of the total order per address when
opaque is used?

--0000000000009b502a05c9a6a13f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi,</div><div><br></div><div>One of the many definiti=
ons of coherence is the following:</div><div>1) a total order of all loads/=
stores per address.<br></div><div>2) a load needs to see the most recent st=
ore before it in the coherence order.</div><div>3) the coherence order shou=
ld be compatible with the (preserved) program order of each thread.</div><d=
iv><br></div><div>There are important relaxations:<br></div><div><br></div>=
<div>1) The actual order of loads and stores isn&#39;t relevant, it is all =
about keeping up appearances. So in theory the above requirements can be vi=
olated, as long as nobody can prove it happened. This goes for many other m=
emory models like sequential consistency or TSO. <br></div><div><br></div><=
div>2) Coherence order doesn&#39;t imply any real time guarantees, reads an=
d writes can be skewed similar as with sequential consistency. So a read do=
esn&#39;t need to see the most recent write before it in physical clock ter=
ms; it just needs to return the most recent write before it in the coherenc=
e order.<br></div><div><br></div><div>What i understand from the=C2=A0 info=
rmation about opaque:<br></div><div><a href=3D"http://gee.cs.oswego.edu/dl/=
html/j9mm.html">http://gee.cs.oswego.edu/dl/html/j9mm.html</a></div><div>is=
 that opaque doesn&#39;t provide a total order on a single address. So its =
usage of coherence is slightly different from the general notion of coheren=
ce.<br></div><div><br></div><div>Given the fact that coherence to some exte=
nt is quite relaxed, what is the reason that it wasn&#39;t specified in ter=
ms of a total order? Is it possible, in theory, to observe a violation of t=
he total order per address when opaque is used?<br></div></div>

--0000000000009b502a05c9a6a13f--

--===============8654411808761513226==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Concurrency-interest mailing list
[email protected]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

--===============8654411808761513226==--