3. JMM / what & why?
• JVM observes within-thread as-if-serial semantics;
Sunday, November 4, 12
4. JMM / what & why?
• JVM observes within-thread as-if-serial semantics;
• JMM defines how threads interact through memory;
Sunday, November 4, 12
5. JMM / what & why?
• JVM observes within-thread as-if-serial semantics;
• JMM defines how threads interact through memory;
• JMM answers the main question:
• “When the thread will see changes done in the
other one?”
Sunday, November 4, 12
6. JMM / what & why?
• JVM observes within-thread as-if-serial semantics;
• JMM defines how threads interact through memory;
• JMM answers the main question:
• “When the thread will see changes done in the
other one?”
• why we need it?
• write correct applications;
• avoid over synchronizations.
Sunday, November 4, 12
7. Variable visibility
x = y = 0
Thread 1 Thread 2
a = x b = y
y = 1 x = 1
a = ?
b = ?
Sunday, November 4, 12
8. Variable visibility
x = y = 0
Thread 1 Thread 2
a = x b = y
y = 1 x = 1
a = 0; b = 0;
a = 0; b = 1;
a = 1; b = 0;
a = 1; b = 1;
Sunday, November 4, 12
10. Reordering
• compiler can optimize ops order (w/o changing
application within-thread as-if-serial semantics);
Sunday, November 4, 12
11. Reordering
• compiler can optimize ops order (w/o changing
application within-thread as-if-serial semantics);
• CPU can execute commands in the other order in
some cases;
Sunday, November 4, 12
12. Reordering
• compiler can optimize ops order (w/o changing
application within-thread as-if-serial semantics);
• CPU can execute commands in the other order in
some cases;
• cache can store values back to the main memory in
not the same order as it was written by application;
Sunday, November 4, 12
13. Reordering
• compiler can optimize ops order (w/o changing
application within-thread as-if-serial semantics);
• CPU can execute commands in the other order in
some cases;
• cache can store values back to the main memory in
not the same order as it was written by application;
• etc.
Sunday, November 4, 12
15. Happens-before relationship
• it is a guarantee that memory written to by statement
A is visible to statement B, that is, that A completes
its write before statement B starts its read;
Sunday, November 4, 12
16. Happens-before relationship
• it is a guarantee that memory written to by statement
A is visible to statement B, that is, that A completes
its write before statement B starts its read;
• A happens-before B := hb(A, B);
Sunday, November 4, 12
17. Happens-before relationship
• it is a guarantee that memory written to by statement
A is visible to statement B, that is, that A completes
its write before statement B starts its read;
• A happens-before B := hb(A, B);
• transitive: hb(x, y) & hb (y, z) => hb(x, z).
Sunday, November 4, 12
18. Will T2 see any changes done by T1? #1
Thread 1 Thread 2
⇓ ⇓
y = 2 lock M2
⇓ ⇓
lock M1 temp = x
⇓ ⇓
x = 1 unlock M2
⇓ ⇓
unlock M1 temp2 = y
⇓ ⇓
z = 3 temp3 = z
⇓ ⇓
Sunday, November 4, 12
19. Will T2 see any changes done by T1? #2
Thread 1 Thread 2
⇓ ⇓
y = 2 lock M1
⇓ ⇓
lock M1 temp = x
⇓ ⇓
x = 1 unlock M1
⇓ ⇓
unlock M1 temp2 = y
⇓ ⇓
z = 3 temp3 = z
⇓ ⇓
Sunday, November 4, 12
20. Will T2 see any changes done by T1? #3
Thread 1 Thread 2
⇓ ⇓
y = 2 read M1
⇓ ⇓
volatile M1 temp = x
⇓ ⇓
x = 1 temp2 = y
⇓ ⇓
write M1 temp3 = z
⇓ ⇓
z = 3
⇓
Sunday, November 4, 12
21. Will T2 see any changes done by T1? #4
Thread 1 Thread 2
⇓ ⇓
y = 2 if(!t1.isAlive())
⇓ ⇓
lock M1 temp = x
⇓ ⇓
x = 1 temp2 = y
⇓ ⇓
unlock M1 temp3 = z
⇓ ⇓
z = 3
⇓
Sunday, November 4, 12
22. Will T2 see any changes done by T1? #5
Thread 1 Thread 2
⇓ ⇓
y = 2 Thread.interrupted()
⇓ ⇓
x = 1 temp = x
⇓ ⇓
t2.interrupt() temp2 = y
⇓ ⇓
z = 3 temp3 = z
⇓ ⇓
Sunday, November 4, 12
24. Happens-before rules
• each action A in thread happens-before each action B
(that placed after A in code) in the same thread;
Sunday, November 4, 12
25. Happens-before rules
• each action A in thread happens-before each action B
(that placed after A in code) in the same thread;
• unlock monitor happens-before any following lock on
the same monitor;
Sunday, November 4, 12
26. Happens-before rules
• each action A in thread happens-before each action B
(that placed after A in code) in the same thread;
• unlock monitor happens-before any following lock on
the same monitor;
• write into volatile var happens-before any following
read from the same volatile var;
Sunday, November 4, 12
27. Happens-before rules
• each action A in thread happens-before each action B
(that placed after A in code) in the same thread;
• unlock monitor happens-before any following lock on
the same monitor;
• write into volatile var happens-before any following
read from the same volatile var;
• `Thread.start()` happens-before first action in the
started thread;
Sunday, November 4, 12
28. Happens-before rules
• each action A in thread happens-before each action B
(that placed after A in code) in the same thread;
• unlock monitor happens-before any following lock on
the same monitor;
• write into volatile var happens-before any following
read from the same volatile var;
• `Thread.start()` happens-before first action in the
started thread;
• last action in thread1 happens-before any action in
thread2 if thread2 detects that thread1 ends by
invoking `thread1.join()` or if `thread1.isAlive()`
invoked and `false` returned;
Sunday, November 4, 12
31. Happens-before rules #2
• constructor happens-before finalizer;
• thread interruption happens-before place, where
thread detects that it has been interrupted;
Sunday, November 4, 12
32. Happens-before rules #2
• constructor happens-before finalizer;
• thread interruption happens-before place, where
thread detects that it has been interrupted;
• some more rules...
Sunday, November 4, 12
33. Reordering: synchronized
...
synchronized (this) {
...
...
} // end of synch
...
Sunday, November 4, 12
