• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Long and double is not atomic in java

 
Greenhorn
Posts: 16
IntelliJ IDE Eclipse IDE Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
Why long and double is not atomic in java


Your answer are welcome.
 
Bartender
Posts: 1558
5
Eclipse IDE Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Saloon Keeper
Posts: 7585
176
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 1558
5
Eclipse IDE Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Saloon Keeper
Posts: 7585
176
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Bartender
Posts: 1952
7
Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Master Rancher
Posts: 4806
72
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Master Rancher
Posts: 4806
72
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic