Courses: concurrency #2

523 views

Published on

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
523
On SlideShare
0
From Embeds
0
Number of Embeds
73
Actions
Shares
0
Downloads
6
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Courses: concurrency #2

  1. 1. Java Concurrency #2 Sergey Lukjanov, 2012 slukjanov@mirantis.comSunday, November 4, 12
  2. 2. JMM / what & why?Sunday, November 4, 12
  3. 3. JMM / what & why? • JVM observes within-thread as-if-serial semantics;Sunday, November 4, 12
  4. 4. JMM / what & why? • JVM observes within-thread as-if-serial semantics; • JMM defines how threads interact through memory;Sunday, November 4, 12
  5. 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. 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. 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. 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
  9. 9. ReorderingSunday, November 4, 12
  10. 10. Reordering • compiler can optimize ops order (w/o changing application within-thread as-if-serial semantics);Sunday, November 4, 12
  11. 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. 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. 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
  14. 14. Happens-before relationshipSunday, November 4, 12
  15. 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. 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. 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. 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. 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. 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. 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. 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
  23. 23. Happens-before rulesSunday, November 4, 12
  24. 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. 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. 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. 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. 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
  29. 29. Happens-before rules #2Sunday, November 4, 12
  30. 30. Happens-before rules #2 • constructor happens-before finalizer;Sunday, November 4, 12
  31. 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. 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. 33. Reordering: synchronized ... synchronized (this) { ... ... } // end of synch ...Sunday, November 4, 12
  34. 34. Reordering: volatile ... volatile write ... ... volatile read ...Sunday, November 4, 12
  35. 35. Volatile guaranteesSunday, November 4, 12
  36. 36. Volatile guarantees • happens-before;Sunday, November 4, 12
  37. 37. Volatile guarantees • happens-before; • reordering;Sunday, November 4, 12
  38. 38. Volatile guarantees • happens-before; • reordering; • atomic read/write (including Long and Double at i386)Sunday, November 4, 12
  39. 39. ExamplesSunday, November 4, 12

×