Thread.sleep makes compiler read value every time

Question

In java specification 17.3. Sleep and Yield, it says

It is important to note that neither Thread.sleep nor Thread.yield have any synchronization semantics.

This sentence is the point. If I replace Thread.sleep(100) by System.out.println("") in my test code below, the compiler always read iv.stop every time because System.out.println("") acquires a lock, check this question. Java specification says Thread.sleep does not have any synchronization semantics, so I wonder what makes compiler treat Thread.sleep(100) as same as System.out.println("").

My test code:

public class InfiniteLoop {
    boolean stop = false;

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

        final InfiniteLoop iv = new InfiniteLoop();

        Thread t1 = new Thread(() -> {
            while (!iv.stop) {
                //uncomment this block of code, loop broken
//                try {
//                    Thread.sleep(100);
//                } catch (InterruptedException e) {
//                    e.printStackTrace();
//                }
            }
            System.out.println("done");
        });

        Thread t2 = new Thread(() -> {
            try {
                Thread.sleep(100);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            iv.stop = true;
        });
        t1.start();
        t2.start();
    }
}

As the comment above says, Thread.sleep() breaks the loop, this is different from the description of the Java specification: why?

Answer 1

Let's see what the docs actually says:

The compiler is free to read the field this.done just once, and reuse the cached value in each execution of the loop. This would mean that the loop would never terminate, even if another thread changed the value of this.done.

See the highlighted word "free"? "free" means that the compiler can either read this.done once, or not. It's the compiler's choice. That's what "free" means. Your loop breaks because the compiler sees your code and thought "I am going to read iv.stop every time, even though I can read it just once."

In other words, it is not guaranteed to always break the loop. Your code behaves exactly as the docs say.

Answer 2

so I wonder what makes compiler treat Thread.sleep(100) as same as System.out.println("").

Well there is certainly nothing in the language definition that says that they are at all the same. Thread.sleep(...) does not cross any memory barriers while System.out.println(...) does. What you may be seeing is an artifact of how your threaded application is running on your architecture. Maybe the thread gets swapped out because of CPU contention which forces the cache memory to be flushed. If you ran this on a different OS or on hardware with more cores you would most likely not see sleep(...) do anything.

The difference here may also be a compiler optimization. The while loop with nothing in it might not be even checking the value of the stop field since the compiler knows that nothing is updating it inside the loop and it's not volatile. As soon as you add something that does thread state manipulation, it changes the generated code so that the field is then actually paid attention.

Ultimately, the problem is around the publishing of the boolean stop field between threads. The field should be marked as volatile to ensure it is properly shared. As you mentioned, when you call System.out.println(...) this goes in and out of a synchronized block which crosses memory barriers which effectively update the stop field.

Answer 3

Though the question is already answered I don't feel the other answers address the confusion in the question.

If we simplify the code to

while (!iv.stop) {
    // do something ....
}

Then the compiler is free (as others have said) to read iv.stop only once. The important points are:

• To force the compiler to enforce a re-read of iv.stop, it should be declared volatile.

• Without volatile, the compiler may, or may not change whether it decides to re-read iv.stop as a result of changing the loop contents ("do something...") but that cannot be reliably predicted.

• You can't infer anything special in this context about the fact that sleep doesn't use locking semantics

(The third point references what I believe to be the confusion in the question)

So with regards to the issue of println() vs sleep(): The fact that sleep doesn't use locking semantics is irrelevant; println doesn't use locking semantics either.

println implementation may use locking to ensure it's own thread-safety, but that fact is not visible in the scope of the calling code (ie your code). (As a side note, sleep implementation ultimately will use some sort of locking deep down in its implementation (in the native code).

From the API perspective, both sleep and println are static methods which take one parameter, so the compiler is likely to be affected the same way by them, with regards to how it performs optimisations in the surrounding code, but like I said you can't rely on that.