Presentation is loading. Please wait.

Presentation is loading. Please wait.

Mutual Exclusion Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit Modified by Rajeev Alur for CIS 640, Spring.

Published byAnsley Liverpool Modified over 9 years ago

Similar presentations

Presentation on theme: "Mutual Exclusion Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit Modified by Rajeev Alur for CIS 640, Spring."— Presentation transcript:

1 Mutual Exclusion Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit Modified by Rajeev Alur for CIS 640, Spring 2009 University of pennsylvania

2 Art of Multiprocessor Programming 2 Prisoners and a switch puzzle (Distributed coordination) At the start, prisoners get together and decide a strategy, but later have no communication Warden’s office has a switch (on/off) Warden repeatedly picks a prisoner, and brings him to office Prisoner can declare “all have visited the office at least once”, may toggle the switch, or leave it unchanged. Then warden takes prisoner back to his cell

3 Art of Multiprocessor Programming 3 Prisoners and a switch puzzle (Distributed coordination) Assumption about the order in which prisoners are picked: if the prisoner waits long enough, he will get picked (fair scheduling) Goal: Design winning strategy for prisoners so that (1) declaration is never made prematurely (2) eventually some prisoner makes declaration For now, assume: initially switch is off

4 Art of Multiprocessor Programming 4 Solution At the start, prisoners choose one to be the leader, rest act as followers Leader will be the only one to turn switch from on to off, and will count how many times he does this Each follower will turn the switch from off to on, exactly once

5 Art of Multiprocessor Programming 5 Each Follower’s Strategy Local variable done, initially False Upon entry to the room –If Done ==True do nothing –If switch is on, do nothing –If switch is off and Done==False, set Done to True and turn the switch on Exercise: Prove that this solution is correct Design strategy for the case when initial position of switch is not known to prisoners

6 Art of Multiprocessor Programming 6 Leader’s Strategy Local variable count, initially 0 Upon entry to the room –If switch is off, do nothing –If switch is on, increment count and turn the switch off –If count == N-1 then declare that all prisoners have been to the room at least once

7 Art of Multiprocessor Programming 7 Mutual Exclusion Today we will try to formalize our understanding of mutual exclusion We will also use the opportunity to show you how to argue about and prove various properties in an asynchronous concurrent setting

8 Art of Multiprocessor Programming 8 Mutual Exclusion Formal problem definitions Solutions for 2 threads Solutions for n threads Fair solutions Inherent costs

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

10 Art of Multiprocessor Programming10 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

11 Art of Multiprocessor Programming 11 time An event a 0 of thread A is –Instantaneous –No simultaneous events (break ties) a0a0 Events

12 Art of Multiprocessor Programming 12 time A thread A is (formally) a sequence a 0, a 1,... of events –“Trace” model –Notation: a 0  a 1 indicates order a0a0 Threads a1a1 a2a2 …

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

14 Art of Multiprocessor Programming 14 Threads are State Machines Events are transitions a0a0 a1a1 a2a2 a3a3

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

16 Art of Multiprocessor Programming 16 time Thread A Concurrency

17 Art of Multiprocessor Programming 17 time Thread A Thread B Concurrency

18 Art of Multiprocessor Programming 18 time Interleavings Events of two or more threads –Interleaved –Not necessarily independent (why?)

19 Art of Multiprocessor Programming 19 time An interval A 0 =(a 0,a 1 ) is –Time between events a 0 and a 1 a0a0 a1a1 Intervals A0A0

20 Art of Multiprocessor Programming 20 time Intervals may Overlap a0a0 a1a1 A0A0 b0b0 b1b1 B0B0

21 Art of Multiprocessor Programming 21 time Intervals may be Disjoint a0a0 a1a1 A0A0 b0b0 b1b1 B0B0

22 Art of Multiprocessor Programming 22 time Precedence a0a0 a1a1 A0A0 b0b0 b1b1 B0B0 Interval A 0 precedes interval B 0

23 Art of Multiprocessor Programming 23 Precedence Notation: A 0  B 0 Formally, –End event of A 0 before start event of B 0 –Also called “happens before” or “precedes”

24 Art of Multiprocessor Programming 24 Precedence Ordering Never true that A   A If A  B then not true that B  A If A  B & B  C then A  C Funny thing: A  B & B  A might both be false!

25 Art of Multiprocessor Programming 25 Partial Orders (review) Irreflexive: –Never true that A   A Antisymmetric: –If A   B then not true that B   A Transitive: –If A   B & B   C then A   C

26 Art of Multiprocessor Programming 26 Total Orders (review) Also –Irreflexive –Antisymmetric –Transitive Except that for every distinct A, B, –Either A   B or B   A

27 Art of Multiprocessor Programming 27 Repeated Events while (mumble) { a 0 ; a 1 ; } a0ka0k k-th occurrence of event a 0 A0kA0k k-th occurrence of interval A 0 =(a 0,a 1 )

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

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

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

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

32 Art of Multiprocessor Programming 32 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; }}

33 Art of Multiprocessor Programming 33 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

34 Art of Multiprocessor Programming 34 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)

35 Art of Multiprocessor Programming 35 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; }} Critical section

36 Art of Multiprocessor Programming 36 Mutual Exclusion Let CS i k be thread i’s k-th critical section execution

37 Art of Multiprocessor Programming 37 Mutual Exclusion Let CS i k be thread i’s k-th critical section execution And CS j m be thread j’s m-th critical section execution

38 Art of Multiprocessor Programming 38 Mutual Exclusion Let CS i k be thread i’s k-th critical section execution And CS j m be j’s m-th execution Then either – or

39 Art of Multiprocessor Programming 39 Mutual Exclusion Let CS i k be thread i’s k-th critical section execution And CS j m be j’s m-th execution Then either – or CS i k  CS j m

40 Art of Multiprocessor Programming 40 Mutual Exclusion Let CS i k be thread i’s k-th critical section execution And CS j m be j’s m-th execution Then either – or CS i k  CS j m CS j m  CS i k

41 Art of Multiprocessor Programming 41 Deadlock-Free If some thread calls lock() –And never returns –Then other threads must complete lock() and unlock() calls infinitely often System as a whole makes progress –Even if individuals starve

42 Art of Multiprocessor Programming 42 Starvation-Free If some thread calls lock() –It will eventually return Individual threads make progress

43 Art of Multiprocessor Programming 43 Two-Thread vs n -Thread Solutions Two-thread solutions first –Illustrate most basic ideas –Fits on one slide Then n-Thread solutions

44 Art of Multiprocessor Programming 44 class … implements Lock { … // thread-local index, 0 or 1 public void lock() { int i = ThreadID.get(); int j = 1 - i; … } Two-Thread Conventions

45 Art of Multiprocessor Programming 45 class … implements Lock { … // thread-local index, 0 or 1 public void lock() { int i = ThreadID.get(); int j = 1 - i; … } Two-Thread Conventions Henceforth: i is current thread, j is other thread

46 Art of Multiprocessor Programming 46 LockOne class LockOne implements Lock { private boolean[] flag = new boolean[2]; public void lock() { flag[i] = true; while (flag[j]) {} }

47 Art of Multiprocessor Programming 47 LockOne class LockOne implements Lock { private boolean[] flag = new boolean[2]; public void lock() { flag[i] = true; while (flag[j]) {} } Set my flag

48 Art of Multiprocessor Programming 48 class LockOne implements Lock { private boolean[] flag = new boolean[2]; public void lock() { flag[i] = true; while (flag[j]) {} } LockOne Wait for other flag to go false Set my flag

49 Art of Multiprocessor Programming 49 Assume CS A j overlaps CS B k Consider each thread's last (j-th and k-th) read and write in the lock() method before entering Derive a contradiction LockOne Satisfies Mutual Exclusion

50 Art of Multiprocessor Programming 50 write A (flag[A]=true)  read A (flag[B]==false)  CS A write B (flag[B]=true)  read B (flag[A]==false)  CS B From the Code class LockOne implements Lock { … public void lock() { flag[i] = true; while (flag[j]) {} }

51 Art of Multiprocessor Programming 51 read A (flag[B]==false)  write B (flag[B]=true) read B (flag[A]==false)  write A (flag[A]=true) From the Assumption

52 Art of Multiprocessor Programming 52 Assumptions: –read A (flag[B]==false)  write B (flag[B]=true) –read B (flag[A]==false)  write A (flag[A]=true) From the code –write A (flag[A]=true)  read A (flag[B]==false) –write B (flag[B]=true)  read B (flag[A]==false) Combining

53 Art of Multiprocessor Programming 53 Assumptions: –read A (flag[B]==false)  write B (flag[B]=true) –read B (flag[A]==false)  write A (flag[A]=true) From the code –write A (flag[A]=true)  read A (flag[B]==false) –write B (flag[B]=true)  read B (flag[A]==false) Combining

54 Art of Multiprocessor Programming 54 Assumptions: –read A (flag[B]==false)  write B (flag[B]=true) –read B (flag[A]==false)  write A (flag[A]=true) From the code –write A (flag[A]=true)  read A (flag[B]==false) –write B (flag[B]=true)  read B (flag[A]==false) Combining

55 Art of Multiprocessor Programming 55 Assumptions: –read A (flag[B]==false)  write B (flag[B]=true) –read B (flag[A]==false)  write A (flag[A]=true) From the code –write A (flag[A]=true)  read A (flag[B]==false) –write B (flag[B]=true)  read B (flag[A]==false) Combining

56 Art of Multiprocessor Programming 56 Assumptions: –read A (flag[B]==false)  write B (flag[B]=true) –read B (flag[A]==false)  write A (flag[A]=true) From the code –write A (flag[A]=true)  read A (flag[B]==false) –write B (flag[B]=true)  read B (flag[A]==false) Combining

57 Art of Multiprocessor Programming 57 Assumptions: –read A (flag[B]==false)  write B (flag[B]=true) –read B (flag[A]==false)  write A (flag[A]=true) From the code –write A (flag[A]=true)  read A (flag[B]==false) –write B (flag[B]=true)  read B (flag[A]==false) Combining

58 Art of Multiprocessor Programming 58 Cycle! Impossible in partial a order

59 Art of Multiprocessor Programming 59 Deadlock Freedom LockOne Fails deadlock-freedom –Concurrent execution can deadlock –Sequential executions OK flag[i] = true; flag[j] = true; while (flag[j]){} while (flag[i]){}

60 Art of Multiprocessor Programming 60 LockTwo public class LockTwo implements Lock { private int victim; public void lock() { victim = i; while (victim == i) {}; } public void unlock() {} }

61 Art of Multiprocessor Programming 61 LockTwo public class LockTwo implements Lock { private int victim; public void lock() { victim = i; while (victim == i) {}; } public void unlock() {} } Let other go first

62 Art of Multiprocessor Programming 62 LockTwo public class LockTwo implements Lock { private int victim; public void lock() { victim = i; while (victim == i) {}; } public void unlock() {} } Wait for permission

63 Art of Multiprocessor Programming 63 LockTwo public class Lock2 implements Lock { private int victim; public void lock() { victim = i; while (victim == i) {}; } public void unlock() {} } Nothing to do

64 Art of Multiprocessor Programming 64 public void LockTwo() { victim = i; while (victim == i) {}; } LockTwo Claims Satisfies mutual exclusion –If thread i in CS –Then victim == j –Cannot be both 0 and 1 Not deadlock free –Sequential execution deadlocks –Concurrent execution does not

65 Art of Multiprocessor Programming 65 Peterson’s Algorithm public void lock() { flag[i] = true; victim = i; while (flag[j] && victim == i) {}; } public void unlock() { flag[i] = false; }

66 Art of Multiprocessor Programming 66 Peterson’s Algorithm public void lock() { flag[i] = true; victim = i; while (flag[j] && victim == i) {}; } public void unlock() { flag[i] = false; } Announce I’m interested

67 Art of Multiprocessor Programming 67 Peterson’s Algorithm public void lock() { flag[i] = true; victim = i; while (flag[j] && victim == i) {}; } public void unlock() { flag[i] = false; } Announce I’m interested Defer to other

68 Art of Multiprocessor Programming 68 Peterson’s Algorithm public void lock() { flag[i] = true; victim = i; while (flag[j] && victim == i) {}; } public void unlock() { flag[i] = false; } Announce I’m interested Defer to other Wait while other interested & I’m the victim

69 Art of Multiprocessor Programming 69 Peterson’s Algorithm public void lock() { flag[i] = true; victim = i; while (flag[j] && victim == i) {}; } public void unlock() { flag[i] = false; } No longer interested Announce I’m interested Defer to other Wait while other interested & I’m the victim

70 Art of Multiprocessor Programming 70 public void lock() { flag[i] = true; victim = i; while (flag[j] && victim == i) {}; Mutual Exclusion If thread 1 in critical section, –flag[1]=true, –victim = 0 If thread 0 in critical section, –flag[0]=true, –victim = 1 Cannot both be true

71 Art of Multiprocessor Programming 71 Deadlock Free Thread blocked –only at while loop –Only if other’s flag is true –only if it is the victim Solo: other’s flag is false Both: one or the other must not be the victim public void lock() { … while (flag[j] && victim == i) {};

72 Art of Multiprocessor Programming 72 Starvation Free Thread i blocked only if j repeatedly re-enters so that flag[j] == true and victim == i When j re-enters –it sets victim to j. –So i gets in public void lock() { flag[i] = true; victim = i; while (flag[j] && victim == i) {}; } public void unlock() { flag[i] = false; }

73 Art of Multiprocessor Programming 73 The Filter Algorithm for n Threads There are n-1 “waiting rooms” called levels At each level –At least one enters level –At least one blocked if many try Only one thread makes it through ncs cs

74 Art of Multiprocessor Programming 74 Filter class Filter implements Lock { int[] level; // level[i] for thread i int[] victim; // victim[L] for level L public Filter(int n) { level = new int[n]; victim = new int[n]; for (int i = 1; i < n; i++) { level[i] = 0; }} … } level victim n -1 0 1 0000004 2 2 Thread 2 at level 4 0 4

75 Art of Multiprocessor Programming 75 Filter class Filter implements Lock { … public void lock(){ for (int L = 1; L < n; L++) { level[i] = L; victim[L] = i; while ((   k != i level[k] >= L) && victim[L] == i ); }} public void unlock() { level[i] = 0; }}

76 Art of Multiprocessor Programming 76 class Filter implements Lock { … public void lock() { for (int L = 1; L < n; L++) { level[i] = L; victim[L] = i; while ((   k != i) level[k] >= L) && victim[L] == i); }} public void release(int i) { level[i] = 0; }} Filter One level at a time

77 Art of Multiprocessor Programming 77 class Filter implements Lock { … public void lock() { for (int L = 1; L < n; L++) { level[i] = L; victim[L] = i; while ((   k != i) level[k] >= L) && victim[L] == i); // busy wait }} public void release(int i) { level[i] = 0; }} Filter Announce intention to enter level L

78 Art of Multiprocessor Programming 78 class Filter implements Lock { int level[n]; int victim[n]; public void lock() { for (int L = 1; L < n; L++) { level[i] = L; victim[L] = i; while ((   k != i) level[k] >= L) && victim[L] == i); }} public void release(int i) { level[i] = 0; }} Filter Give priority to anyone but me

79 Art of Multiprocessor Programming 79 class Filter implements Lock { int level[n]; int victim[n]; public void lock() { for (int L = 1; L < n; L++) { level[i] = L; victim[L] = i; while ((   k != i) level[k] >= L) && victim[L] == i); }} public void release(int i) { level[i] = 0; }} Filter Wait as long as someone else is at same or higher level, and I’m designated victim

80 Art of Multiprocessor Programming 80 class Filter implements Lock { int level[n]; int victim[n]; public void lock() { for (int L = 1; L < n; L++) { level[i] = L; victim[L] = i; while ((   k != i) level[k] >= L) && victim[L] == i); }} public void release(int i) { level[i] = 0; }} Filter Thread enters level L when it completes the loop

81 Art of Multiprocessor Programming 81 Claim Start at level L=0 At most n-L threads enter level L Mutual exclusion at level L=n-1 ncs csL=n-1 L=1 L=n-2 L=0

82 Art of Multiprocessor Programming 82 Induction Hypothesis Assume all at level L-1 enter level L A last to write victim[L] B is any other thread at level L No more than n-L+1 at level L-1 Induction step: by contradiction ncs cs L-1 has n-L+1 L has n-L assume prove

83 Art of Multiprocessor Programming 83 Proof Structure ncs cs Assumed to enter L-1 By way of contradiction all enter L n-L+1 = 4 A B Last to write victim[L] Show that A must have seen B in level[L] and since victim[L] == A could not have entered

84 Art of Multiprocessor Programming 84 No Starvation Filter Lock satisfies properties: –Just like Peterson Alg at any level –So no one starves But what about fairness? –Threads can be overtaken by others

85 Art of Multiprocessor Programming 85 Bounded Waiting Want stronger fairness guarantees Thread not “overtaken” too much Need to adjust definitions ….

86 Art of Multiprocessor Programming 86 Bounded Waiting Divide lock() method into 2 parts: –Doorway interval: Written D A always finishes in finite steps –Waiting interval: Written W A may take unbounded steps

87 Art of Multiprocessor Programming 87 For threads A and B: –If D A k  D B j A’s k-th doorway precedes B’s j-th doorway –Then CS A k  CS B j A’s k-th critical section precedes B’s j-th critical section B cannot overtake A First-Come First-Served

88 Art of Multiprocessor Programming 88 Fairness Again Filter Lock satisfies properties: –No one starves –But very weak fairness Can be overtaken arbitrary # of times –That’s pretty lame…

89 Art of Multiprocessor Programming 89 Bakery Algorithm Provides First-Come-First-Served How? –Take a “number” –Wait until lower numbers have been served Lexicographic order –(a,i) > (b,j) If a > b, or a = b and i > j

90 Art of Multiprocessor Programming 90 Bakery Algorithm class Bakery implements Lock { boolean[] flag; Label[] label; public Bakery (int n) { flag = new boolean[n]; label = new Label[n]; for (int i = 0; i < n; i++) { flag[i] = false; label[i] = 0; } …

91 Art of Multiprocessor Programming 91 Bakery Algorithm class Bakery implements Lock { boolean[] flag; Label[] label; public Bakery (int n) { flag = new boolean[n]; label = new Label[n]; for (int i = 0; i < n; i++) { flag[i] = false; label[i] = 0; } … n -1 0 fffftft 2 f 0000504 0 6 CS

92 Art of Multiprocessor Programming 92 Bakery Algorithm class Bakery implements Lock { … public void lock() { flag[i] = true; label[i] = max(label[0], …,label[n-1])+1; while (  k flag[k] && (label[i],i) > (label[k],k)); }

93 Art of Multiprocessor Programming 93 Bakery Algorithm class Bakery implements Lock { … public void lock() { flag[i] = true; label[i] = max(label[0], …,label[n-1])+1; while (  k flag[k] && (label[i],i) > (label[k],k)); } Doorway

94 Art of Multiprocessor Programming 94 Bakery Algorithm class Bakery implements Lock { … public void lock() { flag[i] = true; label[i] = max(label[0], …,label[n-1])+1; while (  k flag[k] && (label[i],i) > (label[k],k)); } I’m interested

95 Art of Multiprocessor Programming 95 Bakery Algorithm class Bakery implements Lock { … public void lock() { flag[i] = true; label[i] = max(label[0], …,label[n-1])+1; while (  k flag[k] && (label[i],i) > (label[k],k)); } Take increasing label (read labels in some arbitrary order)

96 Art of Multiprocessor Programming 96 Bakery Algorithm class Bakery implements Lock { … public void lock() { flag[i] = true; label[i] = max(label[0], …,label[n-1])+1; while (  k flag[k] && (label[i],i) > (label[k],k)); } Someone is interested

97 Art of Multiprocessor Programming 97 Bakery Algorithm class Bakery implements Lock { boolean flag[n]; int label[n]; public void lock() { flag[i] = true; label[i] = max(label[0], …,label[n-1])+1; while (  k flag[k] && (label[i],i) > (label[k],k)); } Someone is interested With lower (label,i) in lexicographic order

98 Art of Multiprocessor Programming 98 Bakery Algorithm class Bakery implements Lock { … public void unlock() { flag[i] = false; }

99 Art of Multiprocessor Programming 99 Bakery Algorithm class Bakery implements Lock { … public void unlock() { flag[i] = false; } No longer interested labels are always increasing

100 Art of Multiprocessor Programming 100 No Deadlock There is always one thread with earliest label Ties are impossible (why?)

101 Art of Multiprocessor Programming 101 First-Come-First-Served If D A  D B then A’s label is smaller And: –write A (label[A])  read B (label[A])  write B (label[B])  read B (flag[A]) So B is locked out while flag[A] is true class Bakery implements Lock { public void lock() { flag[i] = true; label[i] = max(label[0], …,label[n-1])+1; while (  k flag[k] && (label[i],i) > (label[k],k)); }

102 Art of Multiprocessor Programming 102 Mutual Exclusion Suppose A and B in CS together Suppose A has earlier label When B entered, it must have seen –flag[A] is false, or –label[A] > label[B] class Bakery implements Lock { public void lock() { flag[i] = true; label[i] = max(label[0], …,label[n-1])+1; while (  k flag[k] && (label[i],i) > (label[k],k)); }

103 Art of Multiprocessor Programming 103 Mutual Exclusion Labels are strictly increasing so B must have seen flag[A] == false

104 Art of Multiprocessor Programming 104 Mutual Exclusion Labels are strictly increasing so B must have seen flag[A] == false Labeling B  read B (flag[A])  write A (flag[A])  Labeling A

105 Art of Multiprocessor Programming 105 Mutual Exclusion Labels are strictly increasing so B must have seen flag[A] == false Labeling B  read B (flag[A])  write A (flag[A])  Labeling A Which contradicts the assumption that A has an earlier label

106 Art of Multiprocessor Programming 106 Bakery Y2 32 K Bug class Bakery implements Lock { … public void lock() { flag[i] = true; label[i] = max(label[0], …,label[n-1])+1; while (  k flag[k] && (label[i],i) > (label[k],k)); }

107 Art of Multiprocessor Programming 107 Bakery Y2 32 K Bug class Bakery implements Lock { … public void lock() { flag[i] = true; label[i] = max(label[0], …,label[n-1])+1; while (  k flag[k] && (label[i],i) > (label[k],k)); } Mutex breaks if label[i] overflows

108 Art of Multiprocessor Programming 108 Does Overflow Actually Matter? Yes –Y2K –18 January 2038 (Unix time_t rollover) –16-bit counters No –64-bit counters Maybe –32-bit counters

109 Art of Multiprocessor Programming 109 Is this Optimal Solution? The Bakery Algorithm is –Succinct, –Elegant, and –Fair. Q: So why isn’t it practical? A: Well, you have to read N distinct variables

110 Art of Multiprocessor Programming 110 Shared Memory Shared read/write memory locations called Registers (historical reasons) Come in different flavors –Multi-Reader-Single-Writer ( Flag[] ) –Multi-Reader-Multi-Writer (Victim [] ) –Not that interesting: SRMW and SRSW

111 Art of Multiprocessor Programming 111 Theorem At least N MRSW (multi- reader/single-writer) registers are needed to solve deadlock-free mutual exclusion. N registers like Flag[]…

112 Art of Multiprocessor Programming 112 Proving Algorithmic Impossibility CS write C To show no algorithm exists: assume by way of contradiction one does, show a bad execution that violates properties: in our case assume an alg for deadlock free mutual exclusion using < N registers

113 Art of Multiprocessor Programming 113 Proof: Need N-MRSW Registers Each thread must write to some register …can’t tell whether A is in critical section write CS write A B C

114 Art of Multiprocessor Programming 114 Upper Bound Bakery algorithm –Uses 2N MRSW registers So the bound is (pretty) tight But what if we use MRMW registers? –Like victim[] ?

115 Art of Multiprocessor Programming 115 Bad News Theorem At least N MRMW multi- reader/multi-writer registers are needed to solve deadlock-free mutual exclusion. (So multiple writers don’t help)

116 Art of Multiprocessor Programming 116 Theorem (For 2Threads) Theorem: Deadlock-free mutual exclusion for 2 threads requires at least 2 multi-reader multi-writer registers Proof: assume one register suffices and derive a contradiction

117 Art of Multiprocessor Programming 117 Two Thread Execution Threads run, reading and writing R Deadlock free so at least one gets in B A CS Write(R) CS R

118 Art of Multiprocessor Programming 118 Covering State for One Register Always Exists Write(R) B In any protocol B has to write to the register before entering CS, so stop it just before

119 Art of Multiprocessor Programming 119 Proof: Assume Cover of 1 A B Write(R) CS A runs, possibly writes to the register, enters CS

120 Art of Multiprocessor Programming 120 Proof: Assume Cover of 1 A B CS B Runs, first obliterating any trace of A, then also enters the critical section Write(R) CS

121 Art of Multiprocessor Programming 121 Theorem Deadlock-free mutual exclusion for 3 threads requires at least 3 multi- reader multi-writer registers

122 Art of Multiprocessor Programming 122 Proof: Assume Cover of 2 Write(R B ) B Write(R C ) C A Only 2 registers

123 Art of Multiprocessor Programming 123 Run A Solo Write(R B ) B Write(R C ) C A Writes to one or both registers, enters CS CS

124 Art of Multiprocessor Programming 124 Obliterate Traces of A Write(R B ) B Write(R C ) C A Other threads obliterate evidence that A entered CS CS

125 Art of Multiprocessor Programming 125 Mutual Exclusion Fails Write(R B ) B Write(R C ) C A CS CS looks empty, so another thread gets in

126 Art of Multiprocessor Programming 126 Proof Strategy Proved: a contradiction starting from a covering state for 2 registers Claim: a covering state for 2 registers is reachable from any state where CS is empty

127 Art of Multiprocessor Programming 127 If we run B through CS 3 times, B must return twice to cover some register, say R B Covering State for Two Write(R B ) B Write(R A ) A

128 Art of Multiprocessor Programming 128 Covering State for Two Start with B covering register R B for the 1 st time Run A until it is about to write to uncovered R A Are we done? Write(R B ) B Write(R A ) A

129 Art of Multiprocessor Programming 129 Covering State for Two NO! A could have written to R B So CS no longer looks empty Write(R B ) B Write(R A ) A

130 Art of Multiprocessor Programming 130 Covering State for Two Run B obliterating traces of A in R B Run B again until it is about to write to R B Now we are done Write(R B ) B Write(R A ) A

131 Art of Multiprocessor Programming 131 Inductively We Can Show There is a covering state –Where k threads not in CS cover k distinct registers –Proof follows when k = N-1 Write(R B ) B Write(R C ) C Write(R A ) A

132 Art of Multiprocessor Programming 132 Summary of Lecture In the 1960’s many incorrect solutions to starvation-free mutual exclusion using RW-registers were published… Today we know how to solve FIFO N thread mutual exclusion using 2N RW-Registers

133 Art of Multiprocessor Programming 133 Summary of Lecture N RW-Registers inefficient – Because writes “cover” older writes Need stronger hardware operations –that do not have the “covering problem”

134 Art of Multiprocessor Programming 134 Muddy children’s puzzle (Common Knowledge) A group of kids are playing. A stranger walks by and announces “Some of you have mud on your forehead Each kid can see everyone else’s forehead, but not his/her own (and they don’t talk to one another) Stranger says “Raise your hand if you conclude that you have mud on your forehead”. Nobody does. Stranger keeps on repeating the statement. If k kids have muddy foreheads, then exactly these k kids raise their hands after the stranger repeats the statement exactly k times

Download ppt "Mutual Exclusion Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit Modified by Rajeev Alur for CIS 640, Spring."

Similar presentations

Mutual Exclusion Companion slides for

Mutual Exclusion Companion slides for
Mutual Exclusion – SW & HW By Oded Regev. Outline: Short review on the Bakery algorithm Short review on the Bakery algorithm Black & White Algorithm Black.

Mutual Exclusion – SW & HW By Oded Regev. Outline: Short review on the Bakery algorithm Short review on the Bakery algorithm Black & White Algorithm Black.
CIS 540 Principles of Embedded Computation Spring 2015 Instructor: Rajeev Alur

CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
CSC321 Concurrent Programming: §3 The Mutual Exclusion Problem 1 Section 3 The Mutual Exclusion Problem.

CSC321 Concurrent Programming: §3 The Mutual Exclusion Problem 1 Section 3 The Mutual Exclusion Problem.
Ch. 7 Process Synchronization (1/2) 2015-04-17. 7.I Background F Producer - Consumer process :  Compiler, Assembler, Loader, · · · · · · F Bounded buffer.

Ch. 7 Process Synchronization (1/2) I Background F Producer - Consumer process :  Compiler, Assembler, Loader, · · · · · · F Bounded buffer.
Process Synchronization Continued 7.2 The Critical-Section Problem.

Process Synchronization Continued 7.2 The Critical-Section Problem.
Mutual Exclusion By Shiran Mizrahi. Critical Section class Counter { private int value = 1; //counter starts at one public Counter(int c) { //constructor.

Mutual Exclusion By Shiran Mizrahi. Critical Section class Counter { private int value = 1; //counter starts at one public Counter(int c) { //constructor.
Silberschatz, Galvin and Gagne ©2007 Operating System Concepts with Java – 7 th Edition, Nov 15, 2006 Chapter 6 (a): Synchronization.

Silberschatz, Galvin and Gagne ©2007 Operating System Concepts with Java – 7 th Edition, Nov 15, 2006 Chapter 6 (a): Synchronization.
1 Chapter 2 Synchronization Algorithms and Concurrent Programming Gadi Taubenfeld © 2007 Synchronization Algorithms and Concurrent Programming Gadi Taubenfeld.

1 Chapter 2 Synchronization Algorithms and Concurrent Programming Gadi Taubenfeld © 2007 Synchronization Algorithms and Concurrent Programming Gadi Taubenfeld.
Chapter 6: Process Synchronization

Chapter 6: Process Synchronization
Silberschatz, Galvin and Gagne ©2013 Operating System Concepts – 9 th Edition Chapter 5: Process Synchronization.

Silberschatz, Galvin and Gagne ©2013 Operating System Concepts – 9 th Edition Chapter 5: Process Synchronization.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Chapter 6: Process Synchronization.

Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Chapter 6: Process Synchronization.
Multiprocessor Synchronization Algorithms (20225241) Lecturer: Danny Hendler The Mutual Exclusion problem.

Multiprocessor Synchronization Algorithms ( ) Lecturer: Danny Hendler The Mutual Exclusion problem.
Process Synchronization. Module 6: Process Synchronization Background The Critical-Section Problem Peterson’s Solution Synchronization Hardware Semaphores.

Process Synchronization. Module 6: Process Synchronization Background The Critical-Section Problem Peterson’s Solution Synchronization Hardware Semaphores.
Chair of Software Engineering Concurrent Object-Oriented Programming Prof. Dr. Bertrand Meyer Lecture 4: Mutual Exclusion.

Chair of Software Engineering Concurrent Object-Oriented Programming Prof. Dr. Bertrand Meyer Lecture 4: Mutual Exclusion.
Mutual Exclusion.

Mutual Exclusion.
Monitors & Blocking Synchronization 1. Producers & Consumers Problem Two threads that communicate through a shared FIFO queue. These two threads can’t.

Monitors & Blocking Synchronization 1. Producers & Consumers Problem Two threads that communicate through a shared FIFO queue. These two threads can’t.
Chapter 3 The Critical Section Problem

Chapter 3 The Critical Section Problem
Parallel Processing (CS526) Spring 2012(Week 6).  A parallel algorithm is a group of partitioned tasks that work with each other to solve a large problem.

Parallel Processing (CS526) Spring 2012(Week 6).  A parallel algorithm is a group of partitioned tasks that work with each other to solve a large problem.
CIS 540 Principles of Embedded Computation Spring 2015 Instructor: Rajeev Alur

CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur

Similar presentations

Ads by Google