When the scheduler can get a thread back to runnable state?

[Stoian Azarov]

If we are have such scenario:

public class Worker extends Thread {
	
	public static int x = 0; 
	
	public void run() {
		x = x + 10;
	}
	
	public static void main(String... args) throws InterruptedException {
		Thread t1 = new Worker();
		Thread t2 = new Worker();
		t1.start();
		t2.start();
		t1.join();
		t2.join();
		System.out.println("x = " + x);
		
	}
}

Is it possible for the scheduler to take a thread back to runnable state in the middle of an instruction?

I was curious if such scenario is possible:
1. t1 reads the value of x(but not the whole instruction is executed)
2. Scheduler gets t1 to runnable and starts to execute t2 instead
3. t2 executes the whole run method(increases x with 10)
4. Scheduler again swaps both threads.
5. t1 already has the value of x=0(which is incorrect - t2 has changed it to 10)
6. t1 finishes the instruction and the final value of x is 10

[Stoian Azarov]

I have done some more testing and it seems that my scenario is impossible.
I hope I am not making wrong assumption

[Henry Wong]

Stoian Azarov wrote:I have done some more testing and it seems that my scenario is impossible.

The JVM spec goes into a ton of detail of how atomic instructions are (along what sorts of optimizations can happen when dealing with volatile variables and synchronization blocks).

Basically, getting an int is atomic, setting an int is atomic, so.... getting the value of x to use is atomic, the line "x=10" is atomic, but "x = x + 10" which both gets and sets the variable x, is *not* atomic.

The variable x is not declared as volatile, nor is synchronization used, some optimizations, such as caching it to a register may also be used. This second case, likely doesn't have any affect, as there is no need to cache unless you intend to reused, such as in a loop.

So... it is possible to end up with the variable x with a value of 10.

Henry

[Stoian Azarov]

Thank you Henry for your valuable response.

I will definitely read more about this topic starting from JVM specification and the info provided by you is a good start.

[Naveen Madarapu]

@Stoian Azarov
are you run this code i got 20 as output

x is static here right ?

[nitin sethi]

Henry Wong wrote:

Stoian Azarov wrote:I have done some more testing and it seems that my scenario is impossible.

The JVM spec goes into a ton of detail of how atomic instructions are (along what sorts of optimizations can happen when dealing with volatile variables and synchronization blocks).

Basically, getting an int is atomic, setting an int is atomic, so.... getting the value of x to use is atomic, the line "x=10" is atomic, but "x = x + 10" which both gets and sets the variable x, is *not* atomic.

The variable x is not declared as volatile, nor is synchronization used, some optimizations, such as caching it to a register may also be used. This second case, likely doesn't have any affect, as there is no need to cache unless you intend to reused, such as in a loop.

So... it is possible to end up with the variable x with a value of 10.

Henry

Hi Henry,

I believe you replied without taking into consideration the below lines of code. Isn't the output always 20 for the OP's code since the below lines do synchronize the run method.

    t1.join();  
    t2.join(); 

Is my below understanding correct?

1. Since x=x+10 is a non-atomic operation, a thread say t1 might read the value of x, sent back to runnable state and then re-start from where it left
( that is increasing the last read value by 10). The other thread t2 may be done with accessing and changing x when the thread t1 was in runnable state. So, both the threads end up changing the value of x to 10.

2. If the variable x is made volatile and the things go as stated in point 1, when the thread t2 changes the variable x, the copy of x with thread t1 also changes to 10 and the value is changed to 20 by thread t1.

I don't get how "optimizations, such as caching it to a register may also be used" to sync the OP's code.

Regards,
Nitin Sethi