aspose file tools*
The moose likes Threads and Synchronization and the fly likes Long and double is not atomic in java Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Long and double is not atomic in java" Watch "Long and double is not atomic in java" New topic
Author

Long and double is not atomic in java

Divya Kumar
Greenhorn

Joined: Mar 26, 2012
Posts: 16

Hi,
Why long and double is not atomic in java


Your answer are welcome.
Anayonkar Shivalkar
Bartender

Joined: Dec 08, 2010
Posts: 1512
    
    5

divya kumar wrote:Hi,
Why long and double is not atomic in java


Your answer are welcome.

Welcome to CodeRanch!

Short answer : its design decision

One reason I can think of is : long and double are 'big' primitives (64 bit). So, at binary level, there are more number of steps involved while doing read-write operations, and hence it would be quite difficult to provide in built atomicity. Further there is always option of volatile variables.

And for the same reason, operations on int and byte are atomic. Those are 16 and 8 bit primitives respectively, and number of steps involved for read-write operation on 32 bit system would be very less, so it is quite easy to provide in built atomicity.

On the other hand, it would be interesting to see if Java supports (or planning to support) atomicity for long and double on 64 bit system and 64 bit JVM. All pointers are appreciated.

I hope this helps.


Regards,
Anayonkar Shivalkar (SCJP, SCWCD, OCMJD, OCEEJBD)
Tim Moores
Rancher

Joined: Sep 21, 2011
Posts: 2408
Anayonkar Shivalkar wrote:it would be interesting to see if Java supports (or planning to support) atomicity for long and double on 64 bit system and 64 bit JVM.

It already does: See AtomicLong.
Anayonkar Shivalkar
Bartender

Joined: Dec 08, 2010
Posts: 1512
    
    5

Tim Moores wrote:
Anayonkar Shivalkar wrote:it would be interesting to see if Java supports (or planning to support) atomicity for long and double on 64 bit system and 64 bit JVM.

It already does: See AtomicLong.

Thanks a lot
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

divya kumar wrote:Hi,
Why long and double is not atomic in java


When Java first came out in 1994 or so, 32-bit hardware was the norm (or was on the way to becoming the norm). Now, roughly 18 years later, it's still the most common, though 64-bit machines are becoming more common.

Java's long and double are 64-bit quantities, so low-level writes on 32-bit hardware are not atomic. The designers of Java probably figured it would make JVM's easier to write and faster to run if they didn't require atomicity for quantities that were bigger than the word width of the most common hardware of the day.


Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Tim Moores wrote:
Anayonkar Shivalkar wrote:it would be interesting to see if Java supports (or planning to support) atomicity for long and double on 64 bit system and 64 bit JVM.

It already does: See AtomicLong.


And it did long before that class came along in 1.5. See volatilte.
Tim Moores
Rancher

Joined: Sep 21, 2011
Posts: 2408
Jeff Verdegan wrote:And it did long before that class came along in 1.5. See volatilte.

Where do you see the connection between volatile and atomicity - something like this? That was part of Java 5 as well.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Tim Moores wrote:
Jeff Verdegan wrote:And it did long before that class came along in 1.5. See volatilte.

Where do you see the connection between volatile and atomicity - something like this? That was part of Java 5 as well.


Declaring a field volatile makes all its reads and writes atomic. It's been in the JLS at least since 1.2, and probably since 0.9.

True, that doesn't give you things like atomic incrementAndGet() that AtomicLong and AtomicDouble do, but then, you don't get that on the other primitives either without those AtomicXxx classes. It's been my understanding that we were simply talking about the non-atomicity of reads and writes of longs and doubles, in contrast to the atomic reads and writes you get with all other types, and volatile has addressed that particular issue since the old days.
Jelle Klap
Bartender

Joined: Mar 10, 2008
Posts: 1836
    
    7

It depends on how you choose to define atomicity in this context.
A volatile declared long is atomic (pre-Java 5 also) in the sense that it guarantees (for all JVM implementations) a read or write go directly to main memory instead of two 32-bit registers.

Edit: Ugh, too slow.


Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Jelle Klap wrote:It depends on how you choose to define atomicity in this context.
A volatile declared long is atomic (pre-Java 5 also) in the sense that it guarantees (for all JVM implementations) a read or write go directly to main memory instead of two 32-bit registers.


Not just that it goes to main mem, but also that no other thread can see an intermediate state, even if the JVM has to perform two separate operations.
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3018
    
  10
Pre-Java 5, volatile was supposed to provide such guarantees for long and double. However things did not work out this way in practice, and implementations frequently violated this guarantee. As I recall the issue seemed to get fixed around JDK 1.4, but as they were still working on the whole memory model thing, they didn't really make any clear announcements about it until JDK 5, when the new rules were announced, and memory guarantees actually meant something.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Mike Simmons wrote:Pre-Java 5, volatile was supposed to provide such guarantees for long and double. However things did not work out this way in practice,


Right. The wording in the memory model was apparently kind of sloppy and JVM implementations followed the letter of the law but didn't provide the desired results. I'm pretty sure the new memory model was introduced in 1.3 or 1.4 though, not 5.

and implementations frequently violated this guarantee. As I recall the issue seemed to get fixed around JDK 1.4, but as they were still working on the whole memory model thing, they didn't really make any clear announcements about it until JDK 5, when the new rules were announced, and memory guarantees actually meant something.


Okay, I may be mistaken about the fix details.

In any case, though, I was talking about what volatile has always been intended to do, without regard to implementation shortcomings.
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3018
    
  10
Jeff Verdegan wrote:
Mike Simmons wrote:Pre-Java 5, volatile was supposed to provide such guarantees for long and double. However things did not work out this way in practice,


Right. The wording in the memory model was apparently kind of sloppy and JVM implementations followed the letter of the law but didn't provide the desired results. I'm pretty sure the new memory model was introduced in 1.3 or 1.4 though, not 5.

As far as using volatile to prevent word-tearing in long and double, the guarantees in the JLS were always crystal clear. They just weren't followed in most 32-bit implementations. There was vagueness about other issues, which was why JSR-133 went on for a long time, across several releases. I remember running Bill Pugh's AtomicLong test using JDK 1.2 and 1.3 and seeing it fail, and later seeing it pass on JDK 1.4. (This was all using Sun's Windows JDKs.) But I couldn't find a clear announcement of it being officially fixed, just that work was ongoing. It wasn't until JDK 5 that I could find official documentation of the new memory model as something that was "done", apparently.

I think Henry has talked a bit about this stuff, as he was either directly involved, or knows people who were. I seem to recall that for volatile to work correctly on 32-bit machines they had to effectively insert little sync blocks - which was additional overhead that they didn't really want to do without knowing exactly what guarantees the new implementation would be required to adhere to. But I may well be mangling the details there.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Long and double is not atomic in java