Primitive Queue<any T> considerations

[Vitaly Davidovich]

This is good to hear Brian.

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.


Just to spitball this a bit, if the value type is larger than max atomic
transfer unit on the machine, what's the thinking? I suppose you'd need
some locking, but where would it get a lock for this? Would a synthetic one
be generated automatically (javac or JVM)?

On Wed, Nov 18, 2015 at 2:56 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

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