multithreading - Instruction reordering & happens-before relationship in java -

in book java concurrency in practice, told several time instructions of our program can reordered, either compiler, jvm @ runtime, or processor. should assume executed program not have instructions executed in same order specified in source code.

however, last chapter discussing java memory model provides listing of happens-before rules indicating instruction ordering preserved jvm. first of these rules is:

• "program order rule. each action in thread happens before every action in thread comes later in program order."

i believe "program order" refers source code.

my question: assuming rule, wonder instruction may reordered.

"action" defined follow:

the java memory model specified in terms of actions, include reads , writes variables, locks , unlocks of monitors, , starting , joining threads. jmm defines partial ordering called happens before on actions within program. guarantee thread executing action b can see results of action (whether or not , b occur in different threads), there must happens before relationship between , b. in absence of happens before ordering between 2 operations, jvm free reorder them pleases.

other order rules mentionned are:

• monitor lock rule. unlock on monitor lock happens before every subsequent lock on same monitor lock.
• volatile variable rule. write volatile field happens before every subsequent read of same field.
• thread start rule. call thread.start on thread happens before every action in started thread.
• thread termination rule. action in thread happens before other thread detects thread has terminated, either return thread.join or thread.isalive returning false.
• interruption rule. thread calling interrupt on thread happens before interrupted thread detects interrupt (either having interruptedexception thrown, or invoking isinterrupted or interrupted).
• finalizer rule. end of constructor object happens before start of finalizer object.
• transitivity. if happens before b, , b happens before c, happens before c.

the key point of program order rule is: in thread.

imagine simple program (all variables 0):

t1:

x = 5; y = 6; 

t2:

if (y == 6) system.out.println(x); 

from t1's perspective, execution must consistent y being assigned after x (program order). t2's perspective not have case , t2 might print 0.

t1 allowed assign y first 2 assignements independent , swapping them not affect t1's execution.

with proper synchronization, t2 print 5 or nothing.

edit

you seem misinterpreting meaning of program order. the program order rule boils down to:

if x , y actions of same thread , x comes before y in program order, hb(x, y) (i.e. x happens-before y).

happens-before has specific meaning in jmm. in particular, not mean y=6 must subsequent x=5 in t1 wall clock perspective. means sequence of actions executed t1 must consistent with order. can refer jls 17.4.5:

it should noted presence of happens-before relationship between 2 actions does not imply have take place in order in implementation. if reordering produces results consistent legal execution, not illegal.

in example gave above, agree t1's perspective (i.e. in single threaded program), x=5;y=6; consistent y=6;x=5; since don't read values. statement on next line guaranteed, in t1, see 2 actions, regardless of order in performed.