[concurrency-interest] JLS 17.7 Non-atomic treatment of double and long : Android

Aleksey Shipilev aleksey.shipilev at oracle.com
Mon Apr 29 16:59:58 EDT 2013

Yes, that's exactly what I had in mind:
 a. Declare "long a"
 b. Ramp up two threads.
 c. Make thread 1 write 0L and -1L over and over to field $a
 d. Make thread 2 observe the field a, and count the observed values
 e. ...

P.S. It is important to do some action on value read in thread 2, so
that it does not hoisted from the loop, since $a is not supposed to be


On 04/30/2013 12:54 AM, Tim Halloran wrote:
> Thanks Aleksey, can you elaborate on how to reproduce this in the wild?
> Are you thinking of writing xFFFFFFFF_FFFFFFFF (or some known bit
> pattern/long value) and x00000000_0000000 (another known bit
> pattern/long value) from two different threads and seeing if you get
> x00000000_FFFFFFFF or xFFFFFFFF_00000000 -- or did you have another
> scheme in mind.  Best.
> On Mon, Apr 29, 2013 at 4:42 PM, Aleksey Shipilev
> <aleksey.shipilev at oracle.com <mailto:aleksey.shipilev at oracle.com>> wrote:
>     On 04/30/2013 12:27 AM, Tim Halloran wrote:
>     > Does anyone know if Android's Dalvik goes with the recommendation
>     in JLS
>     > 17.7 and avoids splitting 64-bit values. I'm pretty sure most
>     other VMs do.
>     You might safely assume ARM does not have full-width 64-bit reads/writes
>     (it can emulate atomic read/write with LL/SC-ed loop), so I'm pretty
>     sure non-volatile longs are not atomic on most mobile platforms.
>     > After some searching I couldn't find any information and it seems
>     pretty
>     > hard to write code to "test" for this on the VM.
>     It is actually one of the simplest tests for concurrency, and simple
>     enough to reproduce in the wild.
>     -Aleksey.

More information about the Concurrency-interest mailing list