Mutual Exclusion

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