[concurrency-interest] JLS 17.7 Non-atomic treatment of double and long : Android
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.
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
> On 04/30/2013 12:54 AM, Tim Halloran wrote:
> > Thanks Aleksey, can you elaborate on how to reproduce this in the
> > 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
> > 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
> > (it can emulate atomic read/write with LL/SC-ed loop), so I'm
> > sure non-volatile longs are not atomic on most mobile platforms.
> > > After some searching I couldn't find any information and it
> > pretty
> > > hard to write code to "test" for this on the VM.
> > It is actually one of the simplest tests for concurrency, and
> > enough to reproduce in the wild.
> > -Aleksey.
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> <mailto:Concurrency-interest at cs.oswego.edu>
More information about the Concurrency-interest