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

--===============7287815429833443422==
Content-Type: multipart/alternative; boundary="000000000000fcac1f05c9585d50"

--000000000000fcac1f05c9585d50
Content-Type: text/plain; charset="UTF-8"

Hi Alex,

Thanks for your answer. That sounds like a very sensible approach.

I need to think about this.

Regards,

Peter.

On Thu, Aug 12, 2021 at 11:14 AM Alex Otenko <[email protected]>
wrote:

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

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

<div dir=3D"ltr"><div>Hi Alex,</div><div><br></div><div>Thanks for your ans=
wer. That sounds like a very sensible approach. <br><br></div><div>I need t=
o think about this.<br><br></div><div>Regards,<br><br></div><div>Peter.<br>=
</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_=
attr">On Thu, Aug 12, 2021 at 11:14 AM Alex Otenko &lt;<a href=3D"mailto:ol=
[email protected]">[email protected]</a>&gt; wrote:<br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"auto">I tre=
at opaque read/write as part of SO, but which do not introduce SW edges - n=
o 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><div dir=3D"auto"><br></di=
v><div dir=3D"auto">Alex</div></div></div><br><div class=3D"gmail_quote"><d=
iv dir=3D"ltr" class=3D"gmail_attr">On Thu, 12 Aug 2021, 08:52 Peter Veentj=
er via Concurrency-interest, &lt;<a href=3D"mailto:concurrency-interest@cs.=
oswego.edu" target=3D"_blank">[email protected]</a>&gt; wr=
ote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D=
"ltr"><div><div><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 all synchronization actions.<br><br></div>Synchronizes with ord=
er (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 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 t=
he union of the SW and PO.<br><br></div>My question is how do relaxed acces=
s 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 guess the logic=
al solution would be that an opaque read/write is not part of the SO and he=
nce we don&#39;t get this problem.=C2=A0 However now we have the problem th=
at an opaque read/write is not ordered by the HB and we have a data race (r=
ead will still be hb-consistent).<br></div><br></div>I&#39;m running into a=
 similar problem with the acquire/release. Traditionally they are called sy=
nchronization actions since a release-store will prevent any older load/sto=
re 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 so=
me level of=C2=A0 &#39;synchronization&#39;; but is this sufficient for the=
m to be part of the SO order? Or are they excluded from the SO and we end u=
p with a data-race?</div><div><br></div><div>Or could it be that the happen=
s-before model isn&#39;t a suitable model to deal with relaxed access 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>
_______________________________________________<br>
Concurrency-interest mailing list<br>
<a href=3D"mailto:[email protected]" rel=3D"noreferrer" ta=
rget=3D"_blank">[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>
</blockquote></div>

--000000000000fcac1f05c9585d50--

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

--===============7287815429833443422==--