atomicity for value types

[Doug Lea]

On 1/14/20 3:43 PM, John Rose wrote:
> On Jan 14, 2020, at 9:11 AM, Doug Lea <dl at cs.oswego.edu
> <mailto:dl at cs.oswego.edu>> wrote:

>> In which case "__AlwaysOpaque" would be a more accurate term.
> 
> Very interesting!  I guess this is the most relevant definition of opaque:
>   http://gee.cs.oswego.edu/dl/html/j9mm.html#opaquesec
> 
> Doug, in honor of one of your pet expressions, I would have
> preferred to spell this keyword “not-too-tearable”, but
> that’s truly an opaque phrase.


OK; I was concerned that your proposed definition was too strong, but
weaker is fine, because optionally stronger modes can then be accessed
via VarHandles. The term used in JDK9+ memory specs is "bitwise-atomic",
which is one part of Opaque mode (also holding for plain mode <=32bit
and refs). But it is possible and desirable to separate it for sake of
Record types. Perhaps a better term is "integral" (better than
non-tearable). But if we want hyphen-friendly modifiers, just
"bitwise-atomic" works (or __bitwiseAtomic as standin until adopted). As in:

bitwise-atomic inline class Long256 { long v1, v2, v3 ,v4; … }

(Aside: should "bitwise-atomic long" also be a valid type?)

-Doug