Could Java thread.start be reordered?

Question

Consider the following scenario borrowed from Memory Consistency - happens-before relationship in Java:

package happen.before;

public class HappenBeforeRelationship {

private static int counter = 0;

private static void threadPrintMessage(String msg){
    System.out.printf("[Thread %s] %s\n", Thread.currentThread().getName(), msg);
}

public static void main(String[] args) {
    threadPrintMessage("Increase counter: " + ++counter);
    Thread t = new Thread(new CounterRunnable());
    t.start();
    try {
        t.join();
    } catch (InterruptedException e) {
        threadPrintMessage("Counter is interrupted");
    }
    threadPrintMessage("Finish count: " + counter);
}

private static class CounterRunnable implements Runnable {
    @Override
    public void run() {
        threadPrintMessage("start count: " + counter);
        counter++;
        threadPrintMessage("stop count: " + counter);
    }
}

I know there is a rule in JLS guarantees that Thread.start happens before all actions in the started thread.

When a statement invokes Thread.start, every statement that has a happens-before relationship with that statement also has a happens-before relationship with every statement executed by the new thread. The effects of the code that led up to the creation of the new thread are visible to the new thread.

But it does not claim that statements before Thread.start has a happens-before relationship with it.

So I wonder that could Thread.start be reordered so that the program could not get the expected output (counter=2)? If not, which part of JLS specifies that Thread.start could not be reordered?

---

Another question:

What happens if join() is put after threadPrintMessage("Finish count: " + counter);? Is it possible that stop count: 1 is printed?

Answer 1

There is an ordering relationship between the actions before the Thread.start invocation and the start of the new thread due to JLS§17.4.5:

• If x and y are actions of the same thread and x comes before y in program order, then hb(x, y).
• …
• If hb(x, y) and hb(y, z), then hb(x, z).

and later on in the same section, the already mentioned in your question guaranty:

• A call to start() on a thread happens-before any actions in the started thread.

Due to the transitive nature of happens-before relationships, you have a happens-before relationship between the action of the main thread before invoking start() and the actions within the started thread. Similarly, you have a happens-before relationship between the actions of the started thread and a successful return of the main thread’s join invocation.

In other words, as long as you don’t experience an InterruptedException, the updates are properly ordered and the printed result will be 2. This, however does not imply that the actions are never reordered as the JLS§17.4.5 continues:

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.

In other words, happens-before relationships are a high-level concept, that allows you to determine legal results of a program execution. If, like in this example, having 2 in the counter at the end of the program is the only legal outcome (as said, assuming that no interruption occurred), the JVM might arrange the code as much as it wishes, as long as the program will produce the legal outcome of having 2 in the counter at the end.

You should stop bothering about what could be reordered or not. That’s an unimportant implementation detail. In the absence of proper happens-before relationships you might experience updates that appear out-of-order, but also might miss updates or create inconsistent states, so it makes no sense to focus on one implementation detail that could lead to unintended side effects in broken programs. Instead, focus on what makes a correct program.