1 / 128

Mutual Exclusion

Mutual Exclusion. Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit Modified by Pavol Černý , Programming Paradigms for Concurrency , Fall 2010, IST Austria. Review: Peterson’s Algorithm. Bob. flag[0] ←0. flag[1] ←0. Alice. no access.

ownah
Download Presentation

Mutual Exclusion

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Mutual Exclusion Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit Modified by Pavol Černý, Programming Paradigms for Concurrency, Fall 2010, IST Austria

  2. Review: Peterson’s Algorithm Bob flag[0] ←0 flag[1] ←0 Alice no access no access flag[0] ← 1 turn ← 1 flag[1] ← 1 turn ← 0 flag[0] ← 0 flag[0] ← 0 request request flag[0] = 0 or turn = 1 flag[1] = 0 or turn = 0 access access

  3. Implementing a Counter public class Counter { private long value; public long getAndIncrement() { temp = value; value = temp + 1; return temp; } } Use Peterson’s Make these steps indivisible using locks Art of Multiprocessor Programming

  4. Locks (Mutual Exclusion) public interface Lock { public void lock(); public void unlock(); } Art of Multiprocessor Programming

  5. Locks (Mutual Exclusion) public interface Lock { public void lock(); public void unlock(); } acquire lock Art of Multiprocessor Programming

  6. Locks (Mutual Exclusion) public interface Lock { public void lock(); public void unlock(); } acquire lock release lock Art of Multiprocessor Programming

  7. Using Locks public class Counter { private long value; private Locklock; public long getAndIncrement() { lock.lock(); try { inttemp = value; value = value + 1; }finally{ lock.unlock(); } returntemp; }} Art of Multiprocessor Programming

  8. Using Locks public class Counter { private long value; private Lock lock; public long getAndIncrement() { lock.lock(); try { int temp = value; value = value + 1; } finally { lock.unlock(); } return temp; }} acquire Lock Art of Multiprocessor Programming

  9. Using Locks public class Counter { private long value; private Lock lock; public long getAndIncrement() { lock.lock(); try { int temp = value; value = value + 1; } finally { lock.unlock(); } return temp; }} Release lock (no matter what) Art of Multiprocessor Programming

  10. Critical section Using Locks public class Counter { private long value; private Lock lock; public long getAndIncrement() { lock.lock(); try { inttemp = value; value = value + 1; } finally { lock.unlock(); } return temp; }} Art of Multiprocessor Programming

  11. Peterson’s in Java flag[0] ←0 public void lock() { flag[i] = 1; turn = 1-i; while (!((flag[1-i] == 0) || (turn == i))) { } } public void unlock() { flag[i] = 0; } no access flag[0] ← 1 turn ← 1 flag[0] ← 0 request flag[1] = 0 or turn = 0 access

  12. Review: Peterson’s Algorithm • Questions from last lecture: • Can we make do with two shared bits (instead of three)? • How can one extend this idea to n processes? • Does the algorithm work in Java? • Run it and see. What is the problem? • Where is the fault in our proof?

  13. Question 1: Modify Peterson’s to use two bits public void lock() { if (i==0) { flag[0] = 1; while (!(flag[1] == 0)) { } } else { while (!( flag[1] == 1)) {; flag[1] = 1; while (!(flag[0] == 0)) { flag[1] = 0; } } } } public void unlock() { flag[i] = 0; }

  14. Question 2: Modify Peterson’s for n processes Today’s class

  15. Question 3: But does it work in Java? public void lock() { flag[i] = 1; turn = 1-i; while (!((flag[1-i] == 0) || (turn == i))) { } } public void unlock() { flag[i]=0; } java Peterson … (results in deadlock) java Peterson ... (mutual exclusion fails (if a counter is protected with these locks, we observe a problem after enough iterations))

  16. Fact • Most hardware architectures don’t support sequential consistency • Because they think it’s too strong Art of Multiprocessor Programming

  17. time The Flag Example y.read(0) x.write(1) y.write(1) x.read(0) time Art of Multiprocessor Programming

  18. The Flag Example y.read(0) x.write(1) y.write(1) x.read(0) • Each thread’s view is sequentially consistent • It went first time Art of Multiprocessor Programming

  19. The Flag Example y.read(0) x.write(1) y.write(1) x.read(0) • Entire history isn’t sequentially consistent • Can’t both go first time Art of Multiprocessor Programming

  20. The Flag Example y.read(0) x.write(1) y.write(1) x.read(0) • Is this behavior really so wrong? • We can argue either way … time Art of Multiprocessor Programming

  21. Opinion1: It’s Wrong • This pattern • Write mine, read yours • Is exactly the flag principle • Beloved of Alice and Bob • Heart of mutual exclusion • Peterson • Bakery, etc. • It’s non-negotiable! Art of Multiprocessor Programming

  22. Opinion2: But It Feels So Right … • Many hardware architects think that sequential consistency is too strong • Too expensive to implement in modern hardware • OK if flag principle • violated by default • Honored by explicit request Art of Multiprocessor Programming

  23. Who knew you wanted to synchronize? • Writing to memory = mailing a letter • Vast majority of reads & writes • Not for synchronization • No need to idle waiting for post office • If you want to synchronize • Announce it explicitly • Pay for it only when you need it Art of Multiprocessor Programming

  24. Explicit Synchronization • Memory barrier instruction • Flush unwritten caches • Bring caches up to date • Expensive Art of Multiprocessor Programming

  25. Volatile • In Java, can ask compiler to keep a variable up-to-date with volatile keyword • Also inhibits reordering & other “optimizations” • Example: public static volatile int[] flag; public static volatile int z = 0; Art of Multiprocessor Programming

  26. Mutual Exclusion • Problem definitions • Solutions for 2 threads • Solutions for n threads • Fair solutions • Inherent costs Art of Multiprocessor Programming

  27. Warning • You will never use these protocols • Understanding these is necessary • The same issues show up everywhere • Except hidden and more complex Art of Multiprocessor Programming

  28. Formalizing the Problem Two types of formal properties in asynchronous computation: Safety Properties Nothing bad happens ever E.g. Mutual exclusion, No overtaking Liveness Properties Something good happens eventually E.g. Deadlock freedom, Starvation freedom Art of Multiprocessor Programming 28

  29. time Events • An eventa0 of thread A is • Instantaneous • No simultaneous events (break ties) a0 Art of Multiprocessor Programming

  30. time Threads • A threadA is (formally) a sequence a0,a1, ...of events • “Trace” model • Notation: a0a1 indicates order a1 a2 … a0 Art of Multiprocessor Programming

  31. Example Thread Events • Assign to shared variable • Assign to local variable • Invoke method • Return from method • Lots of other things … Art of Multiprocessor Programming

  32. Threads are State Machines a0 a3 Events are transitions a2 a1 Art of Multiprocessor Programming

  33. States • Thread State • Program counter • Local variables • System state • Object fields (shared variables) • Union of thread states Art of Multiprocessor Programming

  34. time Concurrency • Thread A Art of Multiprocessor Programming

  35. time time Concurrency • Thread A • Thread B Art of Multiprocessor Programming

  36. time Interleavings • Events of two or more threads • Interleaved • Not necessarily independent (why?) Art of Multiprocessor Programming

  37. time Intervals • An intervalA0 =(a0,a1) is • Time between events a0 and a1 a0 a1 A0 Art of Multiprocessor Programming

  38. a0 a1 A0 time Intervals may Overlap b0 b1 B0 Art of Multiprocessor Programming

  39. a0 a1 A0 time Intervals may be Disjoint b0 b1 B0 Art of Multiprocessor Programming

  40. a0 a1 A0 time Precedence Interval A0precedes interval B0 b0 b1 B0 Art of Multiprocessor Programming

  41. Precedence • Notation: A0  B0 • Formally, • End event of A0 before start event of B0 • Also called “happens before” or “precedes” Art of Multiprocessor Programming

  42. Precedence Ordering • Never true that AA • If ABthen not true that BA • If AB&BCthen AC • Funny thing: AB&BAmight both be false! Art of Multiprocessor Programming

  43. Partial Orders(review) • Irreflexive: • Never true that AA • Antisymmetric: • If ABthen not true that BA • Transitive: • If AB&BCthen AC Art of Multiprocessor Programming

  44. Total Orders(review) • Also • Irreflexive • Antisymmetric • Transitive • Except that for every distinct A, B, • Either ABorBA Art of Multiprocessor Programming

  45. Repeated Events while (mumble) { a0; a1; } k-th occurrence of event a0 a0k k-th occurrence of interval A0 =(a0,a1) A0k Art of Multiprocessor Programming

  46. Mutual Exclusion • Let CSik be thread i’s k-th critical section execution Art of Multiprocessor Programming

  47. Mutual Exclusion • Let CSik be thread i’s k-th critical section execution • And CSjm be thread j’s m-th critical section execution Art of Multiprocessor Programming

  48. Mutual Exclusion • Let CSik be thread i’s k-th critical section execution • And CSjm be j’s m-th execution • Then either • or Art of Multiprocessor Programming

  49. Mutual Exclusion • Let CSik be thread i’s k-th critical section execution • And CSjm be j’s m-th execution • Then either • or CSikCSjm Art of Multiprocessor Programming

  50. Mutual Exclusion • Let CSik be thread i’s k-th critical section execution • And CSjm be j’s m-th execution • Then either • or CSikCSjm CSjmCSik Art of Multiprocessor Programming

More Related