• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Long and double is not atomic in java

 
Divya Kumar
Greenhorn
Posts: 16
Eclipse IDE IntelliJ IDE Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
Why long and double is not atomic in java


Your answer are welcome.
 
Anayonkar Shivalkar
Bartender
Posts: 1557
5
Eclipse IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Tim Moores
Bartender
Posts: 2895
46
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1557
5
Eclipse IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Bartender
Posts: 2895
46
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1952
7
Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic