1.31k likes | 1.52k Views
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.
E N D
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 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
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
Locks (Mutual Exclusion) public interface Lock { public void lock(); public void unlock(); } Art of Multiprocessor Programming
Locks (Mutual Exclusion) public interface Lock { public void lock(); public void unlock(); } acquire lock Art of Multiprocessor Programming
Locks (Mutual Exclusion) public interface Lock { public void lock(); public void unlock(); } acquire lock release lock Art of Multiprocessor Programming
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
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
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
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
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
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?
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; }
Question 2: Modify Peterson’s for n processes Today’s class
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))
Fact • Most hardware architectures don’t support sequential consistency • Because they think it’s too strong Art of Multiprocessor Programming
time The Flag Example y.read(0) x.write(1) y.write(1) x.read(0) time Art of Multiprocessor Programming
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
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
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
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
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
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
Explicit Synchronization • Memory barrier instruction • Flush unwritten caches • Bring caches up to date • Expensive Art of Multiprocessor Programming
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
Mutual Exclusion • Problem definitions • Solutions for 2 threads • Solutions for n threads • Fair solutions • Inherent costs Art of Multiprocessor Programming
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
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
time Events • An eventa0 of thread A is • Instantaneous • No simultaneous events (break ties) a0 Art of Multiprocessor Programming
time Threads • A threadA is (formally) a sequence a0,a1, ...of events • “Trace” model • Notation: a0a1 indicates order a1 a2 … a0 Art of Multiprocessor Programming
Example Thread Events • Assign to shared variable • Assign to local variable • Invoke method • Return from method • Lots of other things … Art of Multiprocessor Programming
Threads are State Machines a0 a3 Events are transitions a2 a1 Art of Multiprocessor Programming
States • Thread State • Program counter • Local variables • System state • Object fields (shared variables) • Union of thread states Art of Multiprocessor Programming
time Concurrency • Thread A Art of Multiprocessor Programming
time time Concurrency • Thread A • Thread B Art of Multiprocessor Programming
time Interleavings • Events of two or more threads • Interleaved • Not necessarily independent (why?) Art of Multiprocessor Programming
time Intervals • An intervalA0 =(a0,a1) is • Time between events a0 and a1 a0 a1 A0 Art of Multiprocessor Programming
a0 a1 A0 time Intervals may Overlap b0 b1 B0 Art of Multiprocessor Programming
a0 a1 A0 time Intervals may be Disjoint b0 b1 B0 Art of Multiprocessor Programming
a0 a1 A0 time Precedence Interval A0precedes interval B0 b0 b1 B0 Art of Multiprocessor Programming
Precedence • Notation: A0 B0 • Formally, • End event of A0 before start event of B0 • Also called “happens before” or “precedes” Art of Multiprocessor Programming
Precedence Ordering • Never true that AA • If ABthen not true that BA • If AB&BCthen AC • Funny thing: AB&BAmight both be false! Art of Multiprocessor Programming
Partial Orders(review) • Irreflexive: • Never true that AA • Antisymmetric: • If ABthen not true that BA • Transitive: • If AB&BCthen AC Art of Multiprocessor Programming
Total Orders(review) • Also • Irreflexive • Antisymmetric • Transitive • Except that for every distinct A, B, • Either ABorBA Art of Multiprocessor Programming
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
Mutual Exclusion • Let CSik be thread i’s k-th critical section execution Art of Multiprocessor Programming
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
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
Mutual Exclusion • Let CSik be thread i’s k-th critical section execution • And CSjm be j’s m-th execution • Then either • or CSikCSjm Art of Multiprocessor Programming
Mutual Exclusion • Let CSik be thread i’s k-th critical section execution • And CSjm be j’s m-th execution • Then either • or CSikCSjm CSjmCSik Art of Multiprocessor Programming