On atomicity and tearing

[Brian Goetz]

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

Sorry, typo -- s/class/variable/

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

It is true that some data races are benign; the canonical example here 
is the String hashCode.  But this trick is (and should be) exceedingly 
rare, and for purposes of explaining atomicity to the other 99.999% of 
Java users, can be ignored.

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

I think you may be coming at this from a different direction; you've got 
a collection of "interesting corner cases" where a data race might not 
be a problem.  These are really interesting cases, but it's focusing on 
the trees rather than the forest.  We don't want to encourage reasoning 
about "in this case, data race X is OK".  That's a game for experts -- 
and most experts know to try to avoid playing it.

The point is that "bad things happen in data races", and that 
non-atomicity merely *moves the bad things around*.

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

Yes, it basically trades the bad effects of "mutable ref to immutable 
state" for the bad effects of "immutable ref to mutable state".  In the 
latter, more things can go wrong, because there is more mutability.

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