Courses: concurrency #2

39
Java Concurrency #2 Sergey Lukjanov, 2012 [email protected] Sunday, November 4, 12

description

 

Transcript of Courses: concurrency #2

Page 1: Courses: concurrency #2

Java Concurrency #2Sergey Lukjanov, 2012

[email protected]

Sunday, November 4, 12

Page 2: Courses: concurrency #2

JMM / what & why?

Sunday, November 4, 12

Page 3: Courses: concurrency #2

JMM / what & why?• JVM observes within-thread as-if-serial semantics;

Sunday, November 4, 12

Page 4: Courses: concurrency #2

JMM / what & why?• JVM observes within-thread as-if-serial semantics;• JMM defines how threads interact through memory;

Sunday, November 4, 12

Page 5: Courses: concurrency #2

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

Page 6: Courses: concurrency #2

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

Page 7: Courses: concurrency #2

Variable visibility

x = y = 0

Thread 1 Thread 2a = xy = 1

b = yx = 1

a = ?b = ?

Sunday, November 4, 12

Page 8: Courses: concurrency #2

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

Page 9: Courses: concurrency #2

Reordering

Sunday, November 4, 12

Page 10: Courses: concurrency #2

Reordering• compiler can optimize ops order (w/o changing

application within-thread as-if-serial semantics);

Sunday, November 4, 12

Page 11: Courses: concurrency #2

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

Page 12: Courses: concurrency #2

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

Page 13: Courses: concurrency #2

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

Page 14: Courses: concurrency #2

Happens-before relationship

Sunday, November 4, 12

Page 15: Courses: concurrency #2

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

Page 16: Courses: concurrency #2

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

Page 17: Courses: concurrency #2

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

Page 18: Courses: concurrency #2

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

Page 19: Courses: concurrency #2

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

Page 20: Courses: concurrency #2

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

Page 21: Courses: concurrency #2

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

Page 22: Courses: concurrency #2

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

Page 23: Courses: concurrency #2

Happens-before rules

Sunday, November 4, 12

Page 24: Courses: concurrency #2

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

Page 25: Courses: concurrency #2

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

Page 26: Courses: concurrency #2

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

Page 27: Courses: concurrency #2

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

Page 28: Courses: concurrency #2

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

Page 29: Courses: concurrency #2

Happens-before rules #2

Sunday, November 4, 12

Page 30: Courses: concurrency #2

Happens-before rules #2• constructor happens-before finalizer;

Sunday, November 4, 12

Page 31: Courses: concurrency #2

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

Page 32: Courses: concurrency #2

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

Page 33: Courses: concurrency #2

Reordering: synchronized

...synchronized (this) {

...

...} // end of synch...

Sunday, November 4, 12

Page 34: Courses: concurrency #2

Reordering: volatile

...volatile write...

...volatile read...

Sunday, November 4, 12

Page 35: Courses: concurrency #2

Volatile guarantees

Sunday, November 4, 12

Page 36: Courses: concurrency #2

Volatile guarantees• happens-before;

Sunday, November 4, 12

Page 37: Courses: concurrency #2

Volatile guarantees• happens-before;

• reordering;

Sunday, November 4, 12

Page 38: Courses: concurrency #2

Volatile guarantees• happens-before;

• reordering;

• atomic read/write (including Long and Double at i386)

Sunday, November 4, 12

Page 39: Courses: concurrency #2

Examples

Sunday, November 4, 12