Courses: concurrency #2
-
Upload
sergey-lukjanov -
Category
Documents
-
view
110 -
download
0
description
Transcript of Courses: concurrency #2
Java Concurrency #2Sergey Lukjanov, 2012
Sunday, November 4, 12
JMM / what & why?
Sunday, November 4, 12
JMM / what & why?• JVM observes within-thread as-if-serial semantics;
Sunday, November 4, 12
JMM / what & why?• JVM observes within-thread as-if-serial semantics;• JMM defines how threads interact through memory;
Sunday, November 4, 12
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
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
Variable visibility
x = y = 0
Thread 1 Thread 2a = xy = 1
b = yx = 1
a = ?b = ?
Sunday, November 4, 12
Variable visibility
x = y = 0
Thread 1 Thread 2a = xy = 1
b = yx = 1
a = 0; b = 0;a = 0; b = 1;a = 1; b = 0;a = 1; b = 1;
Sunday, November 4, 12
Reordering
Sunday, November 4, 12
Reordering• compiler can optimize ops order (w/o changing
application within-thread as-if-serial semantics);
Sunday, November 4, 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;
Sunday, November 4, 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
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
Happens-before relationship
Sunday, November 4, 12
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
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
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
Will T2 see any changes done by T1? #1
Thread 1⇓
y = 2⇓
lock M1⇓
x = 1⇓
unlock M1⇓
z = 3⇓
Thread 2⇓
lock M2⇓
temp = x⇓
unlock M2⇓
temp2 = y⇓
temp3 = z⇓
Sunday, November 4, 12
Will T2 see any changes done by T1? #2
Thread 1⇓
y = 2⇓
lock M1⇓
x = 1⇓
unlock M1⇓
z = 3⇓
Thread 2⇓
lock M1⇓
temp = x⇓
unlock M1⇓
temp2 = y⇓
temp3 = z⇓
Sunday, November 4, 12
Will T2 see any changes done by T1? #3
Thread 1⇓
y = 2⇓
volatile M1⇓
x = 1⇓
write M1⇓
z = 3⇓
Thread 2⇓
read M1⇓
temp = x⇓
temp2 = y⇓
temp3 = z⇓
Sunday, November 4, 12
Will T2 see any changes done by T1? #4
Thread 1⇓
y = 2⇓
lock M1⇓
x = 1⇓
unlock M1⇓
z = 3⇓
Thread 2⇓
if(!t1.isAlive())⇓
temp = x⇓
temp2 = y⇓
temp3 = z⇓
Sunday, November 4, 12
Will T2 see any changes done by T1? #5
Thread 1⇓
y = 2⇓
x = 1⇓
t2.interrupt()⇓
z = 3⇓
Thread 2⇓
Thread.interrupted()⇓
temp = x⇓
temp2 = y⇓
temp3 = z⇓
Sunday, November 4, 12
Happens-before rules
Sunday, November 4, 12
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
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
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
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
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
Happens-before rules #2
Sunday, November 4, 12
Happens-before rules #2• constructor happens-before finalizer;
Sunday, November 4, 12
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
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
Reordering: synchronized
...synchronized (this) {
...
...} // end of synch...
Sunday, November 4, 12
Reordering: volatile
...volatile write...
...volatile read...
Sunday, November 4, 12
Volatile guarantees
Sunday, November 4, 12
Volatile guarantees• happens-before;
Sunday, November 4, 12
Volatile guarantees• happens-before;
• reordering;
Sunday, November 4, 12
Volatile guarantees• happens-before;
• reordering;
• atomic read/write (including Long and Double at i386)
Sunday, November 4, 12
Examples
Sunday, November 4, 12