<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div data-marker="__QUOTED_TEXT__"><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><br><br><hr id="zwchr"><div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"Brian Goetz" <brian.goetz@oracle.com><br><b>To: </b>"valhalla-spec-experts" <valhalla-spec-experts@openjdk.java.net><br><b>Sent: </b>Wednesday, April 26, 2023 8:13:45 PM<br><b>Subject: </b>On atomicity and tearing</blockquote><div><br></div><div>Hi Brian,<br data-mce-bogus="1"></div><div>I'm now more confused than I was before reading your mail, it seems i've not understand how things are supposed to work.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><br></blockquote></div><div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><font size="4"><font face="monospace">There has been, not
surprisingly, a lot of misunderstanding about atomicity,
non-atomicity, and tearing. In particular, various syntactic
expressions of non-atomicity (e.g., a `non-atomic` class
keyword) tend to confuse users into thinking that non-atomic
access is somehow a *feature*, rather than providing more
precise control over the breakage modes of already-broken
programs (to steer optimizations for non-broken programs.)<br><br>
I've written the following as an attempt to help people
understand the role of atomicity and tearing in the model;
comments are welcome (though let's steer clear of trying to
paint the bikeshed in this thread.)<br><br><br><br>
# Understanding non-atomicity and tearing<br><br>
Almost since the beginning of Project Valhalla, the design has
included some<br>
form of "non-atomicity" or "tearability". Addressing this in
the programming<br>
model is necessary if we are to achieve the heap flattening that
Valhalla wants<br>
to deliver, but unfortunately this aspect of the feature set is
frequently<br>
misunderstood. <br><br>
Whether non-atomicity is expressed syntactically as a class
modifier,<br>
constructor modifier, supertype, or some other means, the
concept is the same: a<br>
class indicates its willingness to give up certain guarantees in
order to gain<br>
additional heap flattening. <br><br>
Unlike most language features, which express either the presence
or absence of<br>
things that are at some level "normal" (e.g., the presence or
absence of `final`<br>
means a class either can be assigned to, or cannot),
non-atomicity is different;<br>
it is about what the possible observable effects are when an
instance of this<br>
class is accessed with a data race. Programs with data races
are _already<br>
broken_, so rather than opting into or out of a feature,
non-atomicity is<br>
expressing a choice between "breakage mode A" and "breakage mode
B".</font></font></blockquote><div><br></div><div>What do you mean by "a class either can be assigned to, or cannot" ?<br data-mce-bogus="1"></div><div>As far as i know a class can not be assigned.</div><div><br data-mce-bogus="1"></div><div>As far as i know, at least in Java, programs with data races are not automatically broken, it depends on if the states produces by the data races are valid states or not.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>The usual example is not declaring a field final even if the field is initialized only once, in the constructor, it may result in a publication issue, a thread can see the instance not fully initialized.</div><div>But it can be a problem or not depending on if the default value of the field is a valid value or not.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>For me, the non-atomicity of a value class may lead to more possible states than with the publication issue where you can only either see the default value or the assigned value.</div><div><br data-mce-bogus="1"></div><div>So I fail to see how the non-atomicity of the value class issue as a different issue than the publication issue. I'm sure i've misunderstood something ?<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Rémi<br data-mce-bogus="1"></div></div></div><br></div></div></body></html>