On atomicity and tearing

[Remi Forax]

From: "Brian Goetz" <brian.goetz at oracle.com> 
To: "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net> 
Sent: Wednesday, April 26, 2023 8:13:45 PM 
Subject: On atomicity and tearing 



Hi Brian, 
I'm now more confused than I was before reading your mail, it seems i've not understand how things are supposed to work. 


BQ_BEGIN


BQ_END


BQ_BEGIN
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.) 

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



# Understanding non-atomicity and tearing 

Almost since the beginning of Project Valhalla, the design has included some 
form of "non-atomicity" or "tearability". Addressing this in the programming 
model is necessary if we are to achieve the heap flattening that Valhalla wants 
to deliver, but unfortunately this aspect of the feature set is frequently 
misunderstood. 

Whether non-atomicity is expressed syntactically as a class modifier, 
constructor modifier, supertype, or some other means, the concept is the same: a 
class indicates its willingness to give up certain guarantees in order to gain 
additional heap flattening. 

Unlike most language features, which express either the presence or absence of 
things that are at some level "normal" (e.g., the presence or absence of `final` 
means a class either can be assigned to, or cannot), non-atomicity is different; 
it is about what the possible observable effects are when an instance of this 
class is accessed with a data race. Programs with data races are _already 
broken_, so rather than opting into or out of a feature, non-atomicity is 
expressing a choice between "breakage mode A" and "breakage mode B". 
BQ_END


What do you mean by "a class either can be assigned to, or cannot" ? 
As far as i know a class can not be assigned. 

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. 

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. 
But it can be a problem or not depending on if the default value of the field is a valid value or not. 

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. 

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 ? 

Rémi 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-experts/attachments/20230426/41f32d53/attachment.htm>