[concurrency-interest] JLS 17.7 Non-atomic treatment of double and long : Android
yankee.sierra at gmail.com
Mon Apr 29 17:16:47 EDT 2013
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
On Mon, Apr 29, 2013 at 4:59 PM, Aleksey Shipilev <
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 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>>
> > 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
> > (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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest