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

--===============1408793886545366915==
Content-Type: multipart/alternative; boundary="0000000000002f20c405c958539a"

--0000000000002f20c405c958539a
Content-Type: text/plain; charset="UTF-8"

I treat opaque read/write as part of SO, but which do not introduce SW
edges - no transitive closure of program orders. They observe each other,
because SO specifies who is before who.

Then acquire/ release introduce corresponding parts of transitive closure.
In the end volatile load/store are just that.

Alex

On Thu, 12 Aug 2021, 08:52 Peter Veentjer via Concurrency-interest, <
[email protected]> wrote:

> 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.
>
>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> [email protected]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>

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

<div dir=3D"auto">I treat opaque read/write as part of SO, but which do not=
 introduce SW edges - no transitive closure of program orders. They observe=
 each other, because SO specifies who is before who.<div dir=3D"auto"><br><=
/div><div dir=3D"auto">Then acquire/ release introduce corresponding parts =
of transitive closure. In the end volatile load/store are just that.<br><di=
v dir=3D"auto"><br></div><div dir=3D"auto">Alex</div></div></div><br><div c=
lass=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, 12 Aug 2=
021, 08:52 Peter Veentjer via Concurrency-interest, &lt;<a href=3D"mailto:c=
[email protected]">[email protected]</a>&g=
t; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><di=
v><div><div><div><div><div><div><div><div>The happens-before (HB) order is =
defined using:<br><br></div>Synchronization order (SO): total order over al=
l synchronization actions.<br><br></div>Synchronizes with order (SW): a sub=
 order of the SO that only orders e.g. a volatile write of X with all subse=
quent volatile reads of X.<br><br></div>Program Order (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 closure of the union of th=
e SW and PO.<br><br></div>My question is how do relaxed access modes like o=
paque and acquire/release fit into the HB?<br><br></div>Let&#39;s start wit=
h opaque; is an opaque write/read part of the SO? If so, then it will be pa=
rt of the SW and HB. And because of this, it will order loads/stores to dif=
ferent addresses which is not desirable. So I guess the logical solution wo=
uld be that an opaque read/write is not part of the SO and hence we don&#39=
;t get this problem.=C2=A0 However now we have the problem that an opaque r=
ead/write is not ordered by the HB and we have a data race (read will still=
 be hb-consistent).<br></div><br></div>I&#39;m running into a similar probl=
em with the acquire/release. Traditionally they are called synchronization =
actions since a release-store will prevent any older load/store to be reord=
ered with the release-store and acquire-load will prevent any later load/st=
ore to be reordered with the acquire-load. So they provide some level of=C2=
=A0 &#39;synchronization&#39;; but is this sufficient for them to be part o=
f the SO order? Or are they excluded from the SO and 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 access modes?<br></div><di=
v><br></div>Regards,<br><br></div>Peter.<br><div><div><br><br><div><div><di=
v><br><br></div></div></div></div></div></div>
_______________________________________________<br>
Concurrency-interest mailing list<br>
<a href=3D"mailto:[email protected]" target=3D"_blank" rel=
=3D"noreferrer">[email protected]</a><br>
<a href=3D"http://cs.oswego.edu/mailman/listinfo/concurrency-interest" rel=
=3D"noreferrer noreferrer" target=3D"_blank">http://cs.oswego.edu/mailman/l=
istinfo/concurrency-interest</a><br>
</blockquote></div>

--0000000000002f20c405c958539a--

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

--===============1408793886545366915==--