To what extent can the VM change order of execution

Question

Hi
I've been reading a book named "Java Threads, Third Edition" from O'Reilly Media by Scott Oaks and Henry Wong. The book has a subchapter named "The Effect of Reordering Statements" where it states that the vm is free to change the order of executement, and that the order of operations can therefore not be used to ensure that a class/code is threadsafe. Ill just point a snip from the book to illustrate. The example code:
public int currentScore, totalScore, finalScore
public void resetScore(boolean done) {
    totalScore += currentScore;
    if (done) {
        finalScore = totalScore;
        currentScore = 0;
public int getFinalScore( ) {
    if (currentScore == 0{)
        return finalScore;
    return -1;
}It then suggest that these two runs can take place. Run 1:
- Thread1: Update total score
- Thread2: See if currentScore == 0
- Thread2: Return -1
- Thread1: Update finalScore
- Thread1: Set currentScore == 0
Run 2:
- Thread1: Update total score
- Thread1: Set currentScore == 0
- Thread2: See if currentScore == 0
- Thread2: Return finalScore
- Thread1: Update finalScore
My question now is if this info is correct, and if so, to what extent can the vm rearange the order of executement? Say I have this code (simplified example):
class SelectorThread implements Runnable{
private volatile boolean keepRunning;
public void run(){
   while(keepRunning){
       //Dosomething
        internalSelector.select();
public void stopIt(){
    keepRunning = false;
     internalSelector.wakeup();
}Would it then be possible for the vm to rearrange the code in stopIt(), thus making it possible to get a : "T1: wake up selector, T2: selector checks keepRunning, T2: selector goes back to sleep, T1: keepRunning is changed to false" scenario? Or is the above code "safe" to use?

Answer 1

Thanks for the answer :)
Am I then right in concluding that the stopIT() method I described is then not guarantueed to deliver the wanted result? (that the select thread exits the loop). If the vm-orders the statements as you show and the thread timing is a bit unlucky you could end up with:
Thread A (the one calling stopIT()) executes internalSelector.wakeup();
Thread B (the thread in the loop) wakes up
Thread B checks the while condition which still evalutes true and ends back with blocking on .select()
Thread A changes the value of keepRunning to false
Thereby possibly leaving threadB blocked "forever" if no other events occur.
Is this intepretation of the mechanicm correct? meaning do I need to change the implementation of the stopIt() method to assure it will produce the wanted result?