Re: "liveness" requirements for acquire/release

--===============0263725563408126369==
Content-Type: multipart/alternative; boundary="000000000000c3d7aa05dcdcc0bc"

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

"Staleness" has no definition.

The actual guarantee is: if release is before acquire in the total order of
operations on that variable, the read is going to see the write. "Not
stale", in other words. The trick is in ordering the releases and acquires.

Ale

On Sun, 17 Apr 2022, 18:00 Govind Jajoo via Concurrency-interest, <
[email protected]> wrote:

> Hello Concurrency-Interest!
>
> Given a class like the following
>
> /*******************/
> class ContrivedAcquireReleaseExample {
>   static class Wrapper {
>     Object value;
>   }
>
>   AtomicReference<Wrapper> holder = new AtomicReference<>(new Wrapper());
>
>   public void setValue(Object newVal) {
>     var wrapper = holder.getAcquire();
>     wrapper.value = newVal;
>     holder.setRelease(wrapper);
>   }
>
>   public Object getValue() {
>     return holder.getAcquire().value;
>   }
> }
> /*******************/
>
> Is there anything that prohibits a confirming JVM from optimizing the
> setValue above to effectively the following?
>
> public void setValue(Object newVal) {
>     wrapper.value = newVal;
> }
>
> (I imagine a reader that keeps reading a "stale" value can always be
> considered to have had its acquire execute at some previously set holder
> value.)
>
> What are the "liveness" requirements if any, around how stale can the
> acquire be?
>
> Thanks for reading.
>
> Govind
> _______________________________________________
> Concurrency-interest mailing list
> [email protected]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>

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

<div dir=3D"auto">&quot;Staleness&quot; has no definition.<div dir=3D"auto"=
><br></div><div dir=3D"auto">The actual guarantee is: if release is before =
acquire in the total order of operations on that variable, the read is goin=
g to see the write. &quot;Not stale&quot;, in other words. The trick is in =
ordering the releases and acquires.</div><div dir=3D"auto"><br></div><div d=
ir=3D"auto">Ale=C2=A0</div></div><br><div class=3D"gmail_quote"><div dir=3D=
"ltr" class=3D"gmail_attr">On Sun, 17 Apr 2022, 18:00 Govind Jajoo via Conc=
urrency-interest, &lt;<a href=3D"mailto:[email protected]"=
>[email protected]</a>&gt; wrote:<br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr"><div><font face=3D"monospace">Hello Concur=
rency-Interest!</font></div><div><font face=3D"monospace"><br></font></div>=
<font face=3D"monospace">Given a class like the following<br><br>/*********=
**********/<br>class ContrivedAcquireReleaseExample {<br>=C2=A0 static clas=
s Wrapper {<br>=C2=A0 =C2=A0 Object value;<br>=C2=A0 }<br><br>=C2=A0 Atomic=
Reference&lt;Wrapper&gt; holder =3D new AtomicReference&lt;&gt;(new Wrapper=
());<br><br>=C2=A0 public void setValue(Object newVal) {<br>=C2=A0 =C2=A0 v=
ar wrapper =3D holder.getAcquire();<br>=C2=A0 =C2=A0 wrapper.value =3D newV=
al;<br>=C2=A0 =C2=A0 holder.setRelease(wrapper);<br>=C2=A0 }</font><div><fo=
nt face=3D"monospace"><br>=C2=A0 public Object getValue() {<br>=C2=A0 =C2=
=A0 return holder.getAcquire().value;<br>=C2=A0 }<br>}</font><div><span sty=
le=3D"font-family:monospace">/*******************/</span><br style=3D"font-=
family:monospace"></div><div><span style=3D"font-family:monospace"><br></sp=
an></div><div><font face=3D"monospace">Is there anything that prohibits a c=
onfirming JVM from optimizing the setValue above to effectively the followi=
ng?<br><br>public void setValue(Object newVal) {<br>=C2=A0 =C2=A0 wrapper.v=
alue =3D newVal;<br>}<br></font></div></div><div><font face=3D"monospace"><=
br></font></div><div><font face=3D"monospace">(I imagine a</font><span styl=
e=3D"font-family:monospace">=C2=A0reader that keeps reading a &quot;stale&q=
uot; value can always be considered to have had its acquire execute at some=
 previously set holder value.)=C2=A0</span></div><div><span style=3D"font-f=
amily:monospace"><br></span></div><div><span style=3D"font-family:monospace=
">What are the &quot;liveness&quot; requirements if any, around how stale c=
an the acquire be?</span><br></div><div><span style=3D"font-family:monospac=
e"><br></span></div><div><span style=3D"font-family:monospace">Thanks for r=
eading.</span></div><div><br></div><div><span style=3D"font-family:monospac=
e">Govind<br></span></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>

--000000000000c3d7aa05dcdcc0bc--

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

--===============0263725563408126369==--