Re: Working with threads. Example from java docs
Progzmaster wrote:
There is a paragraph:
--------------------------------------------------------------------------------------------------------------------
If, in the following example, one thread repeatedly calls the method one
(but no more than Integer.MAX_VALUE times in all), and another thread
repeatedly calls the method two:
class Test {
static int i = 0, j = 0;
static void one() { i++; j++; }
static void two() {
System.out.println("i=" + i + " j=" + j);
}
I think that what they try to say (saying that it might happen that j>i
at some time, for some thread) is: There is no guarantee that the
compiler generates code that update fields in the same order as the
update operations are written:
-- OK if there is an update and then a read, then the order of the two
is preserved.
-- If you use the volatile keyword, then such a guarantee WILL be made.
-- If you use the synchronized keyword, there is no guarantee. On the
other hand, no other thread is allowed to break in between updates (and
get surprised), so any effect is completely hidden.
In your case, a compiler is free to translate one() to something like:
1) Push i on stack
2) Run a pop-off-stack-add-one-and-push-back-on-stack JVM instruction (I
think there even is such an instruction!)
3) Push j on stack
4) Run a pop-off-stack-add-one-and-push-back-on-stack JVM instruction
5) pop-off-stack, store into j location
6) pop-off-stack, store into i location
It will work fine, but see how j is written back before i in step 5-6??
If the other thread takes over between steps 5 and 6, it will see j>i.
I guess you can reproduce only if your compiler does it this way. It
might also do the steps in the order 1-2-6-3-4-5.
Soren