Reads and writes are atomic for reference variables and for most primitive variables (all types except long and double).
Can some one be kind enough to tell me why is there a exception to long and double primitive data types.
Because double and long are 8 bytes length (64-bits),
and 16-bit processors have only instructions that operate on maximum 32-bits operands, but not on 64-bits.
In other words - 16-bit processor can read or write 32-bits from/to memory in one operation, but for variables that are 64-bits long requires more than 1 operation.
Tim Moores
Rancher
Joined: Sep 21, 2011
Posts: 2329
posted
0
16-bit processors
I don't think any of those can run a modern JVM :-) Most processors these days are 64 bit processors, with some 32 bit ones left over from a few years ago. Whether or not any given CPU can handle 64 bit chunks of data depends on the CPU; most can.
I think the limitation is a leftover from the days where the JVM could only handle 32 bit quantities, and would thus need several steps to handle 64 bit data types (and not just a single one, which would be atomic). I'm not sure if modern 64 bit JVMs are changing anything about this; the Java Language Specification might say something about that.
Reads and writes are atomic for reference variables and for most primitive variables (all types except long and double).
Can some one be kind enough to tell me why is there a exception to long and double primitive data types.
Also, if the variables are declared as volatile, then reads and writes are atomic, even for long and double primatives types.... or basically, you can regard it as atomic for everything; as if you don't declare it as volatile, the variables may be cached, which is not good if you are trying to use the variables without synchronization.
volatile for long and double are treated as atomic, if in the 16 bit processor still we cannot read it in 1 operation..
How does the JVM manage to maintain it atomic?
Jeff Verdegan
Bartender
Joined: Jan 03, 2004
Posts: 3141
posted
0
Rajesh Nagaraju wrote:volatile for long and double are treated as atomic, if in the 16 bit processor still we cannot read it in 1 operation..
How does the JVM manage to maintain it atomic?
Because our Java code doesn't run on the hardware CPU. It runs in the JVM. Even in a 32-bit processor, doubles and longs are two words. The JVM controls the execution of our instructions, so it can make sure that our instructions always see certain operations as atomic, even if the hardware doesn't support that. Just like we can used the synchronized keyword to make long, complex operations atomic in our code, so can the JVM use the underlying native API's multithreading features to make its operations atomic.
At the bare minimum, all that is required is that the hardware provides an atomic test-and-set operation, or some equivalent mutual exclusion feature. If that's present, anything can be made atomic. If it's not, nothing can.
Rajesh Nagaraju wrote:volatile for long and double are treated as atomic, if in the 16 bit processor still we cannot read it in 1 operation..
How does the JVM manage to maintain it atomic?
For 64 bit JVMs, read and writes of doubles and longs are naturally atomic. For 32 bit JVMs, an internal lock is used.
0
