When does java thread cache refresh happens?

Question

Thread 1: is executing this loop

while(running) {
// Do Task()
} 
println("Done");

Thread 2 sets running false In case running is a volatile variable, thread1 comes out of the loop and prints "Done".

My question is if running is not volatile, when does Thread1 reads running variable from the main memory ?

Note: Well i know the happens before relationship about synchronization and volatile variable but the thread 1 does stops even if running is not volatile or synchronized. So my question is when does Thread 1 decides to read from the main memory given that NO SYNCHRONIZATION or and NO VOLATILE

Answer 1

This is described in the JLS under the section Threads and Locks.

When the thread is required to read from main memory is defined in terms of the synchronization order and happens before order. Basically it says that in order for a read to yield the value that was last written, the write needs to happen-before the read.

The happens-before relation is roughly speaking defined in terms of locking/unlocking actions and (with a few exceptions) boils down to the usage of synchronized methods and blocks. Unless you're dealing with volatile variables, the bottom line is usually that you need to synchronize all access to shared data, preferably through AtomicBoolean, a BlockingQueue or some other java.util.concurrent class.

17.4.4 Synchronization Order

Every execution has a synchronization order. A synchronization order is a total order over all of the synchronization actions of an execution. For each thread t, the synchronization order of the synchronization actions (§17.4.2) in t is consistent with the program order (§17.4.3) of t.

Synchronization actions induce the synchronized-with relation on actions, defined as follows:

• An unlock action on monitor m synchronizes-with all subsequent lock actions on m (where subsequent is defined according to the synchronization order).
• A write to a volatile variable (§8.3.1.4) v synchronizes-with all subsequent reads of v by any thread (where subsequent is defined according to the synchronization order).
• An action that starts a thread synchronizes-with the first action in the thread it starts.
• The write of the default value (zero, false or null) to each variable synchronizes-with the first action in every thread. Although it may seem a little strange to write a default value to a variable before the object containing the variable is allocated, conceptually every object is created at the start of the program with its default initialized values.
• The final action in a thread T1 synchronizes-with any action in another thread T2 that detects that T1 has terminated. T2 may accomplish this by calling T1.isAlive() or T1.join().
• If thread T1 interrupts thread T2, the interrupt by T1 synchronizes-with any point where any other thread (including T2) determines that T2 has been interrupted (by having an InterruptedException thrown or by invoking Thread.interrupted or Thread.isInterrupted).

The source of a synchronizes-with edge is called a release, and the destination is called an acquire.

17.4.5 Happens-before Order

Two actions can be ordered by a happens-before relationship. If one action happens-before another, then the first is visible to and ordered before the second.

If we have two actions x and y, we write hb(x, y) to indicate that x happens-before y.

• If x and y are actions of the same thread and x comes before y in program order, then hb(x, y).
• There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (§12.6) for that object.
• If an action x synchronizes-with a following action y, then we also have hb(x, y).
• If hb(x, y) and hb(y, z), then hb(x, z).

It should be noted that the presence of a happens-before relationship between two actions does not necessarily imply that they have to take place in that order in an implementation. If the reordering produces results consistent with a legal execution, it is not illegal.

---

Update: If no happens-before relation exists, the thread is never ever required to "refresh its cache". This question and it's accepted answer provides a concrete example of this.

Here is an slightly modified version of the accepted answer:

public class Test {

    static boolean keepRunning = true;

    public static void main(String[] args) throws InterruptedException {

        (new Thread() {
            public void run() {
                while (keepRunning) {
                }
            }
        }).start();

        System.out.println(keepRunning);
        Thread.sleep(1000);
        keepRunning = false;
        System.out.println(keepRunning);

        // main thread ends here, but the while-thread keeps running.
        // (but not if you change the keepRunning to volatile).
    }
}

Answer 2

I know this is too late to add to the well explained answer. But I hope that some one will get help from my answer.The question was about when does java/jvm thread cache refresh happens?.

There is no way jvm will flush or refresh the local thread cache when thread is in runnable state. But in cases like when thread change its state by itself or external thread scheduler, then definitely local thread cache will flush to main memory. Here I just tweaked the example given from the answer

    (new Thread() {
        public void run() {
            while (keepRunning) {
                LockSupport.parkUntil(500);
            }
        }
    }).start();

    System.out.println(keepRunning);
    Thread.sleep(1000);
    keepRunning = false;
    System.out.println(keepRunning);

Now here I just put the current into waiting thread. This method used by many java built in thread pool executor like common thread pool. So here thread will readfrom main memory and stop itself.

Answer 3

Why not try it yourself?

public class ThreadTest {

private static boolean running = true;

public static void main(String[] args) throws InterruptedException {
    Thread t = new Thread() {
        public void run() {
            while( running ) {
                System.out.println( "Running.");
            }
            long l = System.nanoTime();
            System.out.println( "Stopped at "+l);

        }
    };
    t.start();
    Thread.sleep( 1 );
    running = false;
    long l = System.nanoTime();
    System.out.println( "Stopping at "+l);
}
}

It's by no means a perfect test but it gives you a rough estimate. On my machine the difference was approx 25ms. Of course it has to execute the System.out.println too, but that certainly doesn't take that long.

Answer 4

As thread1 has already read running, it will have a cached value and this will remain valid for some time. This is likely to be us or be ms but could be longer. This is likely to be architecture dependant and also depend on how busy the box is.