divya kumar wrote:Hi,
Why long and double is not atomic in java
Your answer are welcome.
Regards,
Anayonkar Shivalkar (SCJP, SCWCD, OCMJD, OCEEJBD)
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.
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.
Regards,
Anayonkar Shivalkar (SCJP, SCWCD, OCMJD, OCEEJBD)
divya kumar wrote:Hi,
Why long and double is not atomic in java
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.
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.
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.
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.
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,
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 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.
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime. |