Primitive Queue<any T> considerations

[Brian Goetz]

> If value types are final, that means the array-store and array-load 
> have to be atomic in some way for fast-flow to work, i.e., mark has to 
> be written last and read first in the structured array.
>

That would be putting it too strongly.

Your concern is structure tearing.  If thread A writes a value to an 
array element (or a field) and thread B reads it, you are concerned that 
the reader see some consistent value that was put there by a single 
write in the past (even if stale.)

Obviously for "small enough" values, this isn't an issue, but small 
enough is pretty small (64 bits on today's hardware).   Also note that 
the JLS / JVMS have allowed tearing of longs and doubles since day one, 
unless they are declared volatile.

Note that the bad outcome -- tearing -- /only happens in the presence of 
a data race/.  So the question is, what should we do to protect the 
too-clever (and too-unclever) folks from their own mistakes?  The answer 
is certainly not to make all value reads and writes atomics -- this 
would be burdening all of the users who follow the rules with a 
crippling performance penalty (and it is really bad for 
larger-than-64-bit values) for the sake of the few who are living on the 
edge.

So the answer is not "reads and writes need to be atomic", but instead 
"there should be a way to ask for atomic reads/writes."  The current 
front-runner here builds on an existing story -- using volatile to make 
longs/double fields atomic.  We can easily extend this to values.

That leaves two cases uncovered:
  - What about arrays -- there is currently no means to declare an array 
with volatile (or final) elements.  This is being explored now.
  - What about classes that are intrinsically security-sensitive, and 
could not tolerate tearing in any case?  For this case, we are 
considering a declaration-site indication that a value is "unbreakable".

Summary:
  - Tearing is going to be a risk when accessing shared mutable state 
via a data race.
  - There will be use-site and likely also declaration-site tools to opt 
into atomicity, with a cost.