can't understand this program...

[Nikhil Pujari]

I am new to threads, and I must say I have never spent more time understanding any other topic for the SCJP than this. Anyway, I wrote this simple threads program and I can't understand how the result was arrived at. Program and result are shown below.

Program:

package start1;
import java.util.*;

class Nikhil implements Runnable{
  int i=1;
  void doThis(){
    for(i=1;i<=7;){
      System.out.println("i is "+ i +" by "+Thread.currentThread().getName());
      System.out.println("incrementing i, i is "+(++i) +" by thread "+Thread.currentThread().getName());
    }//end of for loop
  }//end of method "doThis"

  public void run(){
    doThis();
  }
} //end of class "Nikhil"

public class Test{
  public static void main(String[] args){
    Nikhil n1=new Nikhil();
    Thread t1=new Thread(n1);
    Thread t2=new Thread(n1);
    t1.start();
    t2.start();
  }
}

result:

i is 1 by Thread-0
i is 1 by Thread-1
incrementing i, i is 2 by thread Thread-0
incrementing i, i is 3 by thread Thread-1
i is 3 by Thread-0
i is 3 by Thread-1
incrementing i, i is 5 by thread Thread-1
i is 5 by Thread-1
incrementing i, i is 4 by thread Thread-0
incrementing i, i is 6 by thread Thread-1
i is 6 by Thread-0
incrementing i, i is 7 by thread Thread-0
i is 6 by Thread-1
i is 7 by Thread-0
incrementing i, i is 8 by thread Thread-1
incrementing i, i is 9 by thread Thread-0

My question is regarding lines 7 and 9.There seems to be a jump in the value of "i" from 3 to 5, without first going thru 4, which shows up later. How can this be possible?

[Alexander Kober]

Standard race condition:

+ T0 and T1 both enter the for loop and execute #8.
+ T0 executes the (++i) in #9 and increments the shared variable.
+ T1 executes the (++i) in #9 as well as the println(...)
+ T0 executes the println(...) in #9.

All you have to keep in mind here is that expressions are evaluated from inside to outside. println(++i) is executed as 1. (++i); 2. println(...);

It is very important to know what operations are executed atomically (as in: This statement executes fully or it doesn't, but there are no intermediate states). By that definition, and this is a common pitfall for people new to threading, (i++) is not atomic either, as it is a shorthand for 1. get i, 2. increment what you got, 3. write the result to i.

[Henry Wong]

To add to that, one of the reasons that this printout is somewhat (relatively) stable, is because the program is doing I/O. The I/O is causing the threads to flush it registers (along with adding time between the portions of code which access the unsafe variable).

If I/O was not done, meaning the loops were doing lots of iterations, there will not only be more "skips" (or "jumps"), but there will also be cases where the value seems to go "backwards". Of course, you won't be able to see it without the I/O printouts -- sort of a case of Schrodinger's Cat ...

Henry

[Nikhil Pujari]

Thanks a ton. The thought that println may not be an atomic operation did cross my mind, but I wasn't sure. Thanks again.

[Jeff Verdegan]

Nikhil Pujari wrote:The thought that println may not be an atomic operation did cross my mind, but I wasn't sure. Thanks again.

No method call is ever atomic. About the only things that are atomic are reading from and writing to variables, except that reading/writing longs and doubles is not atomic if the variables in question are not declared volatile. Of course, we can make any chunk of code behave as if it were atomic with the proper use of synchronization or the higher level constructs in java.util.concurrent.