Java - happens-before relationship for monitor unlock

Question

I have recently read http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html which clearly describes a lot of intrinsics of Java memory model. One particular excerpt got my attention namely:

The rule for a monitorexit (i.e., releasing synchronization) is that 
actions before the monitorexit must be performed before the monitor is released.

Seems obvious to me, however having read http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html and happens-before definition, all I could find about the monitor unblock is when one thread unlocks the monitor that happens-before the other thread locking it again (which makes perfect sense as well). Could someone explain how JLS explains the obvious condition that all the actions within the synchronization block must happen-before the unlock operation?

FURTHER COMMENTS:

Based on a couple of responses I wanted to write up further comments to what you guys have been saying:

1. Reodering within a single-thread

A couple of "truths" from the source I cited:

a = new A()

if new A() involves a hundred operations, followed by assignment of address on a heap to a, compiler can simply reorder those to assign the heap address to a and then follow the usual initialization (problem from double checked locking)

synchronized{
    a = 5;
}
print a;

can be changed to

synchronized{
    a = 5;
    print a;
}

SO we reordered monitorexit with print statement (also valid according to JLS)

Now, the simple case I mentioned:

x = 1;
y = 2;
c = x + y;
print c;

I see no reason that stops a compiler from either assigning x first or y first. There is completely nothing stopping it, as the final output is unchanged regardless of whether x is assigned first or y is. So the reordering is perfectly possible.

1. monitor.unlock

Based on the example with print statement being "pulled into" the synchronization block, let's try to reverse this i.e. startwing with

synchronized{
    a = 5;
    print a;
}

I could expect the compiler to do this:

synchronized{
    a = 5;
}
 print a;

Seems perfectly reasonable within the single-threaded world, YET this is definitely invalid, and against JLS (according to the cited source). Now why is that the case, if I cannot find anything within the JLS about this? and clearly the motivation about the "order of the program" is now irrelevant, since the compiler can make reoderings such as "pulling in" the statements to the synchronized block.

Answer 1

It's not just all actions performed within the synchronized block, it's also referring to all actions by that thread prior to the monitorexit.

Could someone explain how JLS explains the obvious condition that all the actions within the synchronization block must happen-before the unlock operation?

For a particular thread (and only one thread) all actions regardless of synchronized maintains program order, so it appears as if all reads and writes happen in order (we don't need a happens-before ordering in a single-thread case).

The happens-before relationship takes into account multiple threads, that is all actions happening in one thread prior to monitorexit are visible to all threads after a successive monitorenter.

EDIT to address your update.

There are particular rules the compiler must follow to re-order. The specific one in this case is demonstrated in the Can Reorder grid found here

Specifically useful entries are

• First Action: Normal Load (load a; print a)
• Second Action: Monitor Exit

The value here is No meaning the compiler cannot reorder two actions in which the first is a normal load and the second is monitorexit so in your case this reorder would violate the JLS.

There is a rule known as roach-motel ordering, that is read/writes can be reordered into a synchronized block but not out of it.

Answer 2

Maybe you missed this (§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).

Combined with what you already know about happens-before, it should be clear that this implies that all actions preceding the unlock action will be visible to the other thread.

Regarding your additions to the question, if you write this:

synchronized {
    a = 5;
    b = 3;
}

and the compiler emits this:

synchronized{
    a = 5;
}
b = 3;

then the stipulation I have quoted above is violated: now b = 3 does not happen before the lock-release. This is why it is illegal. (Note that your example with print a isn't instructive because it involves only reading + side effects not easily describable with simple variables.)