Happens-before rules in Java Memory Model

Question

I am currently studying for a concurrent programming exam and don't understand why the output of this program is 43. Why is x = y + 1 executed before t.start()? I also should explain which happens-before rules I used.

If I understand the program order rule (each action in a thread happens-before every action in that thread that comes later in the program order) t.start() has to be executed before x = y + 1 so that thread t copies variable x which will be 1.

public class HappensBefore {

static int x = 0;
static int y = 42;

public static void main(String[] args) {
    x = 1;
    Thread t = new Thread() {
        public void run() {
            y = x;
            System.out.println(y);
        };
    };
    t.start();
    x = y + 1;
}

score 9 · Answer 1 · answered Jan 27 '18 at 14:50

9

There is no synchronization, no volatile fields, no locking, no atomic fields. The code can execute in any order.

Yes, t.start() will execute before x = y + 1. But starting the thread doesn't mean the thread body executes before x = y + 1. It could run before, or after, or interleaved with the rest of main().

answered Jan 27 '18 at 14:50

John Kugelman

349,597
67
533
578

so the possible values for y could be 0, 1, or 43? I also have 2 follow up questions: 1) What will be the value that thread t will assign to y? Explain which happens-before rule(s) you used. 2) What will be the value (possible values) that the main thread will assign to y after starting thread t? Explain which happens-before rule(s) you used. What if variable x was volatile? – lmaonuts Jan 27 '18 at 14:55
@lmaonuts I think that `y` can't be `0` because we have `hb(t.start(), y = x)`. You will understand `happens-before` if you understand that. See an example here https://stackoverflow.com/a/48489797/3405171 – v.ladynev Jan 30 '18 at 10:40

St.Antario · Accepted Answer · 2018-01-27T15:53:30.443

According to JMM:

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

and

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

Definition of program order is this:

Among all the inter-thread actions performed by each thread t, the program order of t is a total order that reflects the order in which these actions would be performed according to the intra-thread semantics of t.

The inter-thread semantic is well defined concept in JMM. It means that the order of instructions in a program performed by each thread must be preserved as it is written in the program text.

Applying all these to your case:

t.start(); hb x = y + 1; //program order

t.start(); hb y = x; // happens-before rule specified here

Without additional synchronization we cannot say how x = y + 1; and y = x; relates to each other (From JMM standpoint).

If you are trying to answer the question "What can happen at runtime in my case?". Can happen lots of things... Take a look at this asnwer. Runtime can perform non-trivial optimisations which are consitent with JMM.

Anyway if you are interested about internals you can take a look at this article (Memory Barriers Can Be Avoided). As you can see in the generated assembly, no memory barrier is applied when performing volatile read. I mean that runtime can optimize in anyway... As long the JMM rules are preserved...

Would something change with variable x was volatile? Can we then say the output will always be 43? — lmaonuts, Jan 27 '18 at 15:23
@lmaonuts No, that wouldn't change things. You still don't know which one of `x = y + 1` and `y = x` gets executed first. — Erwin Bolwidt, Jan 27 '18 at 15:25
@lmaonuts No. Let's try to apply JMM to this case. `volatile-write` hb `subsequent volatile-read`. You can only guarantee that **if** the volatile read in `y = x;` happened after the volatile write `x = y + 1;` at runtime then you observe the actual value (read and write of ints are atomic, in case of longs might be a problem... it's not atomic). But `x = y + 1;` and `y = x` still have no happens before. — St.Antario, Jan 27 '18 at 15:42
@lmaonuts Added some article that might be interested to read. — St.Antario, Jan 27 '18 at 15:53

davidxxx · Answer 3 · 2018-01-27T15:47:22.817

If I understand the program order rule (each action in a thread happens-before every action in that thread that comes later in the program order)

No it doesn't.
Here you don't have one thread but two threads : the main thread and the thread created and started by the main thread :

Thread t = new Thread() {...};
t.start();

And living threads of the JVM are by design concurrent.

If the two statements had been executed in the same thread, it would be safe to assume that the value printed out would be "1". But if the two statements are executed in separate threads, the value printed out might well be "0", because there's no guarantee that thread A's change to counter will be visible to thread B — unless the programmer has established a happens-before relationship between these two statements.

The happens-before relationship occurs only if all statements are performed by the same thread or if you explicitly create the happens-before relationship.

Extract from the Memory Consistency Errors tutorial :

There are several actions that create happens-before relationships. One of them is synchronization, as we will see in the following sections.

As said above, the statements are performed by two threads.
And you don't explicitly synchronize statements.
So you have a race condition between the threads and as a general rule, the execution order should be considered as unpredictable. Now in practice, for a such short statement : x = y + 1 :

t.start(); 
x = y + 1;

The assignment of the adding operation is so short to be executed as it is very likely to occur before that the thread referenced by t be effectively run.

Besides, modern CPUs have multiple cores.
So if the CPU has thread availability, the main thread will not be paused to make the new thread running.
The two threads will so be executed at the "same time".
But as x = y + 1; is much faster to be executed as starting and running a thread, the first statement can only finish before the second one.

xingbin · Answer 4 · 2018-01-27T15:04:48.183

2

t.start is before x = y + 1, it does not gurantee every line of code in run() method will be executed before x = y + 1.

In fact, the printed result is uncertain without syncronization because of race condition, it could be 1 or 43.

edited Jan 27 '18 at 15:04

answered Jan 27 '18 at 14:53

xingbin

27,410
9
53
103

When will the output be 2? – lmaonuts Jan 27 '18 at 15:00
@lmaonuts My mistake, it could be 1 or 43. It could not be 0, because `t.start()` happens before the `run` method. – xingbin Jan 27 '18 at 15:06

Oleksandr Pyrohov · Answer 5 · 2018-10-16T17:20:07.737

I would like to add that the code in the main method runs in the Main thread and Thread t doesn't block execution of Main in your example. That's why the line x = y + 1 might be executed faster than the body of the Thread t (as @davidxxx already pointed out).

You can observe different behavior if you add t.join() after t.start():

...
t.start();
t.join();

In this situation, the Main thread will wait for the Thread t to complete and the output will be 1.

Happens-before rules in Java Memory Model

5 Answers5

Linked