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

[Mark Thornton]

On 30/04/13 15:36, Tim Halloran wrote:
> 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.
>
>
> 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 
> implementations)*
>
> 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 specification.
>
> 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.
>
>

Last time I tried this sort of test, a split write would be observed in 
under a second on a true dual processor. However, with only one 
processor available, it would typically take around 20 minutes. So you 
might have to run a very long test to have any real confidence in the 
lack of splitting.

Mark Thornton

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130430/f6c50b6b/attachment.html>