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

Aleksey Shipilev aleksey.shipilev at oracle.com
Mon Apr 29 17:23:14 EDT 2013


Well, yeah, it gets complicated.

But many *practical* cases would still yield the desired result,
probably by coincidence (i.e. you might percieve the "false" acquire
fence from Thread.interrupted() ;)). So then, if that test shows about
the same frequency of 0L and -1L in thread 2, you're fine, otherwise,
fix it by writing/reading the volatile boolean flag in thread 1 / thread
2, rinse and repeat.

-Aleksey.

On 04/30/2013 01:16 AM, Yuval Shavit wrote:
> If the action in thread 2 doesn't update $a, isn't the JVM still within
> its rights to hoist it from the loop? And even if thread 2 does write to
> $a within the loop, isn't the JVM within its rights to update that in
> some register and never write it to main memory where it could interact
> with the writes from thread 1? In other words, in the absence of any HB
> (since $a isn't volatile), can't the JVM just pretend they're entirely
> separate variables?
> 
> 
> On Mon, Apr 29, 2013 at 4:59 PM, Aleksey Shipilev
> <aleksey.shipilev at oracle.com <mailto:aleksey.shipilev at oracle.com>> wrote:
> 
>     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. ...
>      f. PROFIT!
> 
>     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
>     volatile.
> 
>     -Aleksey.
> 
>     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>
>     <mailto: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.
>     >
>     >
> 
>     _______________________________________________
>     Concurrency-interest mailing list
>     Concurrency-interest at cs.oswego.edu
>     <mailto:Concurrency-interest at cs.oswego.edu>
>     http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> 
> 



More information about the Concurrency-interest mailing list