for review: 8236522: "always atomic" modifier for inline classes to enforce atomicity
fw at deneb.enyo.de
Thu Mar 5 17:38:19 UTC 2020
* John Rose:
NonTearable says this:
38 * <p> An inline instance of multiple components is said to be "torn"
39 * when two racing threads compete to update those components, and one
40 * thread updates some components while another thread updates other
41 * components. The resulting inline value stored in the heap might be
I think this description is incorrect: a single writer, single reader
scenario (with final fields in the inline class even) can also result
in invalid values. See “Inline classes and the memory model” posted
today; failed to spot the relevance of this older thread.
I think the actual goal here is to preserve the property that data
races cannot observe out-of-thin-air values, like it is impossible
with a subset of the primitive types? And also to support some
concept of safe publication for inline classes?
More information about the valhalla-dev