n = 0x0000FFFF;
The result will be either 0x0000FFFF or 0xFFFF0000 and never
n = 0xFFFF0000;
array = 0x0000FFFF;
has the same beahvior.
array = 0xFFFF0000;
Make the array volatile.That will not help for two reasons.
Oh, thanks for the clarification. After reading your post, I made a smallThe result will be either 0x0000FFFF or 0xFFFF0000The result (when using a primitive) can actually be
0x00000000 or 0xFFFFFFFF.
both 0x0000FFFF and 0xFFFF0000 unless the variable is
volatile. (The two threads aren't forced to write the
value to main memory)
Oh, thanks for the clarification. After reading yourWithout volatile, one thread could see 0x0000FFFF and the other could see 0xFFFF0000, as each thread can have its own local copy.
post, I made a small
research. Correct me if I'm wrong, but the way I
understand it now is
that, without volatile, the value can be either:
0x0000FFFF or 0xFFFF0000 or whatever value was
there before the
thread(s) executed their code.
Suppose I do not want to synchronize access to arrayThen you can't guarantee correct behavior of things like ++.
It's going degrade performanceHave you measured this, so that you know it will be a problem, or are you just assuming?
but would++ is NOT atomic on anything--variables or array elements. All threading issues are the same for array elements as for variables.
like to understand whether JVM enforces the same
atomic rule on array elements as does with variables.
Can anynody comment on performance? Is it faster toTry it yourself and see if you can even see a meaningful difference.
modify different elements of array versus the same
index? shouldn't the same be slower?