"liveness" requirements for acquire/release

Govind Jajoo via Concurrency-interest <[email protected]> Sun, 17 Apr 2022 18:57:08 +0200
Newsgroups gmane.comp.java.jsr.166-concurrency
Message-ID <CAKy2qXfrK5tTabO9_h_P2_pq7qvjP_fJQ8bxxnSSTDhOn3ARCg@mail.gmail.com>
--===============2633866437118317702==
Content-Type: multipart/alternative; boundary="00000000000066059405dcdc89e3"

--00000000000066059405dcdc89e3
Content-Type: text/plain; charset="UTF-8"

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

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

<div dir=3D"ltr"><div><font face=3D"monospace">Hello Concurrency-Interest!<=
/font></div><div><font face=3D"monospace"><br></font></div><font face=3D"mo=
nospace">Given a class like the following<br><br>/*******************/<br>c=
lass ContrivedAcquireReleaseExample {<br>=C2=A0 static class Wrapper {<br>=
=C2=A0 =C2=A0 Object value;<br>=C2=A0 }<br><br>=C2=A0 AtomicReference&lt;Wr=
apper&gt; holder =3D new AtomicReference&lt;&gt;(new Wrapper());<br><br>=C2=
=A0 public void setValue(Object newVal) {<br>=C2=A0 =C2=A0 var wrapper =3D =
holder.getAcquire();<br>=C2=A0 =C2=A0 wrapper.value =3D newVal;<br>=C2=A0 =
=C2=A0 holder.setRelease(wrapper);<br>=C2=A0 }</font><div><font face=3D"mon=
ospace"><br>=C2=A0 public Object getValue() {<br>=C2=A0 =C2=A0 return holde=
r.getAcquire().value;<br>=C2=A0 }<br>}</font><div><span style=3D"font-famil=
y:monospace">/*******************/</span><br style=3D"font-family:monospace=
"></div><div><span style=3D"font-family:monospace"><br></span></div><div><f=
ont face=3D"monospace">Is there anything that prohibits a confirming JVM fr=
om optimizing the setValue above to effectively the following?<br><br>publi=
c void setValue(Object newVal) {<br>=C2=A0 =C2=A0 wrapper.value =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 style=3D"font-family=
:monospace">=C2=A0reader that keeps reading a &quot;stale&quot; value can a=
lways be considered to have had its acquire execute at some previously set =
holder value.)=C2=A0</span></div><div><span style=3D"font-family:monospace"=
><br></span></div><div><span style=3D"font-family:monospace">What are the &=
quot;liveness&quot; requirements if any, around how stale can the acquire b=
e?</span><br></div><div><span style=3D"font-family:monospace"><br></span></=
div><div><span style=3D"font-family:monospace">Thanks for reading.</span></=
div><div><br></div><div><span style=3D"font-family:monospace">Govind<br></s=
pan></div></div>

--00000000000066059405dcdc89e3--

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

--===============2633866437118317702==--