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

Tim Halloran hallorant at gmail.com
Tue Apr 30 10:36:59 EDT 2013

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
> volatile.
> -Aleksey.
This discussion is getting a bit far afield, I guess, but to get back onto
the topic. I followed Aleksey's advice. And wrote an implementation that
tests this.  I used two separate threads to write 0L and -1L into the long
field "a" but that is the only real change I made. (I already had some
scaffolding code to run things on Android or desktop Java).

*Android: splits writes to longs into two parts.*

On a Samsung Galaxy II with Android 4.0.4  a Nexus 4 phone with Android
4.2.2 I saw non-atomic treatment of long. The value -4294967296
(xFFFFFFFF00000000) showed up as well as 4294967295 (x00000000FFFFFFFF).

So looks like Android does not follow the (albeit optional) advice in the
Java language specification about this.

*JDK: DOES NOT split writes to longs into two parts (even 32-bit

Of course we couldn't get this to happen on any 64-bit JVM, but we tried it
out under Linux on 32-bit OpenJDK 1.7.0_21 it does NOT happen. The 32-bit
JVM implementations follow the recommendation of the Java language

An interesting curio. I wonder how many crashes in "working" Java code
moved from desktop Java onto Android programmers are going to lose sleep
tracking down this one.

Best regards,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130430/2d5a92d6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: device-2013-04-30-102546.png
Type: image/png
Size: 153306 bytes
Desc: not available
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130430/2d5a92d6/attachment-0001.png>

More information about the Concurrency-interest mailing list