Why is 'happens-before; relationship called like that?

I understand everything in this concept, except why is it called like that. Can someone please help me understand it? It still makes me confused.. That is my only question.
I read several articles, I still can't figure out motivation of making its name.

Reading this article will probably help.

The general gist is: The JMM is defined in terms of 'this limited set of events are defined to imply that one thing always happens before the other thing', which is where the term 'happens before' comes from. However, what that boils down to, is this jump in logic: "if the JMM says that A happens before B, what that actually means is that all code after B must be able to observe everything up to A.". Timing rules turn into observation rules.

But that observation rule is what you probably learned and how you understand the JMM, and that's good. However, I assume that 'if you add a synchronized block, it means other threads will observe your changes consistently, whereas if you do not, there is no guarantee that they would' doesn't seem related to the english words 'comes before'. But now you know.

A bit more in-depth

The VM wants to be able to re-order actions, both intra-thread and inter-thread, because that opens the door to optimizations. However, sometimes reordering would break the app. So how does the VM know not to re-order (how does the VM know that re-ordering would break it)? By NOT reordering 2 events if the VM realizes that there is a timing relationship between the 2 events - when the 2 events rely upon the fact that one should happen before the other. The JMM then breaks out which language constructs create such timing relationships, and demands that us java coders write our apps so that if we rely on a certain order, that we use one of these defined happens before relationships so that the VM knows and won't reorder on us.

It's 3 things:

• Imperative: Within a single thread, all statements happen before all further statements - this is the obvious one. In: {x(); y();}, the VM assumes that the java code relies on the x() invoke happening before the y() invoke, whatever x and y are.

• java.lang.Thread: calling .start() on a thread object happens-before that thread actually starting. If a thread .join()s another thread, all actions in the other thread happen-before that join() returns.

• sync primitives - synchronized: If you hit the end of a synchronized() block on object FOO, code relies on the fact that this is fully completed before any other thread would then acquire the lock by starting a synchronized(FOO).

• sync primitives - volatile: field writes happen before later volatile field reads.

So let's go back to what it really means, by way of that last one: It seems tautologous, no? That says: "A thing that happens before another thing, means the other thing happened later". That's like "Circles are round". But it goes to the intent of this stuff and what it really means:

It's not so much about actual execution times. It's about being able to witness the effects of it.

The volatile reads/writes thing is saying:

If thread A so happens to write to a volatile and B so happens to see that write, then that means anything else A did, volatile/synchronized or not, must also be visible to B then.

And thus we have moved from 'timing relationships' to 'visibility relationships', and that latter one is really how the JMM makes sense, and presumably how you understand it. Hopefully now you understand how we got to 'visibility' from 'timing' (and 'happens before' is obvious in light of 'it is about timing', presumably).

Here is an example:

class Example {
    public int field1 = 0;
    public int field2 = 0;

    public void runInA() {
        int f1 = field1, f2 = field2;
        field1 = 5;
        field2 = 10;
        System.out.println(f1 + " " + f2);
    }

    public void runInB() {
        int f1 = field1, f2 = field2;
        field1 = 20;
        field2 = 40;
        System.out.println(f1 + " " + f2);
    }
}

Here it would be acceptable for a VM to end up printing:

0 0
0 40

But that seems to make no sense! (Here thread B ran before A) - but somehow the second field write is visible, but the first one isn't? Huh? - but that's how it works, the JMM makes no guarantees.

Toss in a volatile write, though, and you can no longer observe this.

> A happens-before B does not imply A happening before B.

You're right. And I agree, it's confusing.

Whenever you see "A happens before B" in the Java Language Specification (JLS), you should understand it to mean, "The program must behave as if A happened before B."

The reason they call it "happens before" is to emphasize that it's a transitive relationship: If you know that A "happens before" B, and you also know that B "happens before" C, then you can deduce that A "happens before" C. That is to say, the program must behave as if A actually happens before C.

Here's an example: One rule says,

An unlock on a monitor happens-before every subsequent lock on that monitor.

Seems pretty obvious! How about this one?

If x and y are actions of the same thread and x comes before y in program
order, then [x happens before y].

Do we even need to say that? Yes! because if you put them together, and if you remember to silently insert "the program must behave as if", then you can combine those two rules to reach a useful conclusion:

Suppose that thread 1 stores values into variables a, b, and c; and then it subsequently un-locks a lock. Also suppose that some time later, thread 2 locks the same lock and then it examines a, b, and c.

The first rule says that the program must behave as if the code that you wrote for thread 1 actually did all of the things that you told it to do in the order that you told it to do them (e.g., must assign a, b, and c, before unlocking the lock).

The second rule says that *IF* thread 2 actually does lock the lock after thread 1 released it, then the program must behave as if things really happened in that order. And, going back to the first rule, The program must behave as if thread 2 acquired the lock before it examined a, b, and c.

Put it all together, and you can conclude that the program must behave as if thread 1 wrote a, b, and c, before thread 2 looked at them.

> Also, A happening before B does not imply A happens-before B

Correct. For example, Let's take away the lock.

If thread 1 writes some variables, and then some actual time passes before thread 2 examines the same variables, but there's no locking and nothing else to establish a chain of "happens before" relationships; then the program is NOT required to behave as if the writes happened before the reads. And NOTE! on a modern multi-processor system, it's actually quite likely that the second thread could see an inconsistent view of a, b, and c (e.g., as if the first thread updated a, but not b or c.)

The "Happens before" rules are a formal system that defines how a Java program must behave. If you can't find a chain of "happens before" to prove that your program will behave in some way that you want it to do, then your program is in error: The JLS does not require that it behave in the way that you thought it would behave.