How do relaxed access modes like opaque/acquire/release fit into the happens-before order.

--===============5831318216370828148==
Content-Type: multipart/alternative; boundary="00000000000079287a05c95800ec"

--00000000000079287a05c95800ec
Content-Type: text/plain; charset="UTF-8"

The happens-before (HB) order is defined using:

Synchronization order (SO): total order over all synchronization actions.

Synchronizes with order (SW): a sub order of the SO that only orders e.g. a
volatile write of X with all subsequent volatile reads of X.

Program Order (PO): a partial order that  orders all memory actions issued
by a single CPU.

And the HB relation is defined as the transitive closure of the union of
the SW and PO.

My question is how do relaxed access modes like opaque and acquire/release
fit into the HB?

Let's start with opaque; is an opaque write/read part of the SO? If so,
then it will be part of the SW and HB. And because of this, it will order
loads/stores to different addresses which is not desirable. So I guess the
logical solution would be that an opaque read/write is not part of the SO
and hence we don't get this problem.  However now we have the problem that
an opaque read/write is not ordered by the HB and we have a data race (read
will still be hb-consistent).

I'm running into a similar problem with the acquire/release. Traditionally
they are called synchronization actions since a release-store will prevent
any older load/store to be reordered with the release-store and
acquire-load will prevent any later load/store to be reordered with the
acquire-load. So they provide some level of  'synchronization'; but is this
sufficient for them to be part of the SO order? Or are they excluded from
the SO and we end up with a data-race?

Or could it be that the happens-before model isn't a suitable model to deal
with relaxed access modes?

Regards,

Peter.

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

<div dir=3D"ltr"><div><div><div><div><div><div><div><div><div><div>The happ=
ens-before (HB) order is defined using:<br><br></div>Synchronization order =
(SO): total order over all synchronization actions.<br><br></div>Synchroniz=
es with order (SW): a sub order of the SO that only orders e.g. a volatile =
write of X with all subsequent volatile reads of X.<br><br></div>Program Or=
der (PO): a partial order that=C2=A0 orders all memory actions issued by a =
single CPU.<br><br></div>And the HB relation is defined as the transitive c=
losure of the union of the SW and PO.<br><br></div>My question is how do re=
laxed access modes like opaque and acquire/release fit into the HB?<br><br>=
</div>Let&#39;s start with opaque; is an opaque write/read part of the SO? =
If so, then it will be part of the SW and HB. And because of this, it will =
order loads/stores to different addresses which is not desirable. So I gues=
s the logical solution would be that an opaque read/write is not part of th=
e SO and hence we don&#39;t get this problem.=C2=A0 However now we have the=
 problem that an opaque read/write is not ordered by the HB and we have a d=
ata race (read will still be hb-consistent).<br></div><br></div>I&#39;m run=
ning into a similar problem with the acquire/release. Traditionally they ar=
e called synchronization actions since a release-store will prevent any old=
er load/store to be reordered with the release-store and acquire-load will =
prevent any later load/store to be reordered with the acquire-load. So they=
 provide some level of=C2=A0 &#39;synchronization&#39;; but is this suffici=
ent for them to be part of the SO order? Or are they excluded from the SO a=
nd we end up with a data-race?</div><div><br></div><div>Or could it be that=
 the happens-before model isn&#39;t a suitable model to deal with relaxed a=
ccess modes?<br></div><div><br></div>Regards,<br><br></div>Peter.<br><div><=
div><br><br><div><div><div><br><br></div></div></div></div></div></div>

--00000000000079287a05c95800ec--

--===============5831318216370828148==
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

--===============5831318216370828148==--