Mutual Exclusion Companion slides for © 2003 Herlihy and Shavit Mutual Exclusion Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit

Art of Multiprocessor Programming © 2003 Herlihy and Shavit 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 This lecture covers a number of classical mutual exclusion algorithms that work by reading and writing shared memory. Although these algorithms are not used in practice, we study them because they provide an ideal introduction to the kinds of correctness issues that arise in every area of synchronization. These algorithms, simple as they are, display subtle properties that Students should understand before they are ready to approach the design of truly practical techniques. Art of Multiprocessor Programming

Art of Multiprocessor Programming © 2003 Herlihy and Shavit Mutual Exclusion Formal problem definitions Solutions for 2 threads Solutions for n threads Fair solutions Inherent costs This lecture covers a number of classical mutual exclusion algorithms that work by reading and writing shared memory. Although these algorithms are not used in practice, we study them because they provide an ideal introduction to the kinds of correctness issues that arise in every area of synchronization. These algorithms, simple as they are, display subtle properties that Students should understand before they are ready to approach the design of truly practical techniques. Art of Multiprocessor Programming

Art of Multiprocessor Programming © 2003 Herlihy and Shavit Warning You will never use these protocols Get over it You are advised to understand them The same issues show up everywhere Except hidden and more complex Art of Multiprocessor Programming

Why is Concurrent Programming so Hard? © 2003 Herlihy and Shavit Why is Concurrent Programming so Hard? Try preparing a seven-course banquet By yourself With one friend With twenty-seven friends … Before we can talk about programs Need a language Describing time and concurrency Art of Multiprocessor Programming

Art of Multiprocessor Programming © 2003 Herlihy and Shavit Events An event a0 of thread A is Instantaneous No simultaneous events (break ties) a0 time Art of Multiprocessor Programming

Art of Multiprocessor Programming © 2003 Herlihy and Shavit Threads A thread A is (formally) a sequence a0, a1, ... of events “Trace” model Notation: a0  a1 indicates order a0 a1 a2 … time Art of Multiprocessor Programming

Art of Multiprocessor Programming © 2003 Herlihy and Shavit Example Thread Events Assign to shared variable Assign to local variable Invoke method Return from method Lots of other things … Art of Multiprocessor Programming

Art of Multiprocessor Programming © 2003 Herlihy and Shavit Concurrency Thread A time Art of Multiprocessor Programming

Art of Multiprocessor Programming © 2003 Herlihy and Shavit Concurrency Thread A Thread B time time Art of Multiprocessor Programming

Art of Multiprocessor Programming © 2003 Herlihy and Shavit Interleavings Events of two or more threads Interleaved Not necessarily independent (why?) time Art of Multiprocessor Programming

Art of Multiprocessor Programming © 2003 Herlihy and Shavit Intervals An interval A0 =(a0,a1) is Time between events a0 and a1 a0 a1 A0 time Art of Multiprocessor Programming

Art of Multiprocessor Programming © 2003 Herlihy and Shavit Intervals may Overlap b0 b1 B0 a0 a1 A0 time Art of Multiprocessor Programming

Intervals may be Disjoint © 2003 Herlihy and Shavit Intervals may be Disjoint b0 b1 B0 a0 a1 A0 time Art of Multiprocessor Programming

Precedence Interval A0 precedes interval B0 b0 b1 B0 a0 a1 A0 time © 2003 Herlihy and Shavit Precedence Interval A0 precedes interval B0 b0 b1 B0 a0 a1 A0 time Art of Multiprocessor Programming

Art of Multiprocessor Programming © 2003 Herlihy and Shavit Precedence Notation: A0  B0 Formally, End event of A0 before start event of B0 Also called “happens before” or “precedes” The “arrow” (HAPPENS BEFORE) notation was introduced by Leslie Lamport, a distributed computing pioneer. Art of Multiprocessor Programming

Art of Multiprocessor Programming © 2003 Herlihy and Shavit Precedence Ordering Remark: A0  B0 is just like saying 1066 AD  1492 AD, Middle Ages  Renaissance, Oh wait, what about this week vs this month? Week is concurrent with month, leads into next slide Art of Multiprocessor Programming

Art of Multiprocessor Programming © 2003 Herlihy and Shavit 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! In this slide we deal with concurrent events. Art of Multiprocessor Programming

Implementing a Counter © 2003 Herlihy and Shavit 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 Art of Multiprocessor Programming

Locks (Mutual Exclusion) © 2003 Herlihy and Shavit Locks (Mutual Exclusion) public interface Lock { public void lock(); public void unlock(); } This is the formal definition of a mutual exclusion lock object in java. Art of Multiprocessor Programming

Locks (Mutual Exclusion) © 2003 Herlihy and Shavit Locks (Mutual Exclusion) public interface Lock { public void lock(); public void unlock(); } acquire lock Art of Multiprocessor Programming

Locks (Mutual Exclusion) © 2003 Herlihy and Shavit Locks (Mutual Exclusion) public interface Lock { public void lock(); public void unlock(); } acquire lock release lock Threads using the Lock() and Unlock() methods must follow a specific format, first Lock() then Unlock(). Art of Multiprocessor Programming

Art of Multiprocessor Programming © 2003 Herlihy and Shavit 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; }} In Java, these methods should be used in the following structured way. mutex.lock(); try { ... // body } finally { mutex.unlock(); } Art of Multiprocessor Programming

Art of Multiprocessor Programming © 2003 Herlihy and Shavit 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

Art of Multiprocessor Programming © 2003 Herlihy and Shavit 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

Art of Multiprocessor Programming © 2003 Herlihy and Shavit 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 Art of Multiprocessor Programming

Art of Multiprocessor Programming © 2003 Herlihy and Shavit Mutual Exclusion Let CSik be thread i’s k-th critical section execution The interval CS^k_i is denoted by the . Art of Multiprocessor Programming

Art of Multiprocessor Programming © 2003 Herlihy and Shavit 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

Art of Multiprocessor Programming © 2003 Herlihy and Shavit 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

Art of Multiprocessor Programming © 2003 Herlihy and Shavit 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

Art of Multiprocessor Programming © 2003 Herlihy and Shavit 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

Art of Multiprocessor Programming © 2003 Herlihy and Shavit 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 At least one other thread is completing infinitely often, since there are only a finite number of threads. This is a “Stalinistic” approach. Art of Multiprocessor Programming

Art of Multiprocessor Programming © 2003 Herlihy and Shavit Starvation-Free If some thread calls lock() It will eventually return Individual threads make progress This is a more democratic approach, we want every individual to be happy, not just the system as a whole. Art of Multiprocessor Programming

Two-Thread vs n -Thread Solutions © 2003 Herlihy and Shavit Two-Thread vs n -Thread Solutions Two-thread solutions first Illustrate most basic ideas Fits on one slide Then n-Thread solutions Art of Multiprocessor Programming

Two-Thread Conventions © 2003 Herlihy and Shavit Two-Thread Conventions class … implements Lock { … // thread-local index, 0 or 1 public void lock() { int i = ThreadID.get(); int j = 1 - i; } … will be the lock method we use Art of Multiprocessor Programming

Two-Thread Conventions © 2003 Herlihy and Shavit Two-Thread Conventions class … implements Lock { … // thread-local index, 0 or 1 public void lock() { int i = ThreadID.get(); int j = 1 - i; } LockX will be the lock method we use. We will not mention I and j defs again Henceforth: i is current thread, j is other thread Art of Multiprocessor Programming

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

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

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

LockOne Satisfies Mutual Exclusion © 2003 Herlihy and Shavit LockOne Satisfies Mutual Exclusion Assume CSAj overlaps CSBk Consider each thread's last (j-th and k-th) read and write in the lock() method before entering Derive a contradiction By way of contradiction we make an assumption: both are in the critical sections in overlapping intervals Art of Multiprocessor Programming

Art of Multiprocessor Programming © 2003 Herlihy and Shavit 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]){} The LockOne algorithm is subject to deadlock: if each thread sets its flag to true and waits for the other, they will wait forever, which is the classic definition of a deadlock. Recall that when we looked at the story of Alice and Bob and their pets, this was exactly the first, broken protocol we considered. Art of Multiprocessor Programming

Art of Multiprocessor Programming © 2003 Herlihy and Shavit Peterson’s Algorithm public void lock() { flag[i] = true; victim = i; while (flag[j] && victim == i) {}; } public void unlock() { flag[i] = false; We now combine the two algorithms, one that does not deadlock when they are concurrent, and the other that does not deadlock when they are sequential, to derive an algorithm that never deadlocks. Art of Multiprocessor Programming

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

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

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

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

Art of Multiprocessor Programming © 2003 Herlihy and Shavit Mutual Exclusion public void lock() { flag[i] = true; victim = i; while (flag[j] && victim == i) {}; If thread 0 in critical section, flag[0]=true, victim = 1 If thread 1 in critical section, flag[1]=true, victim = 0 Refer students to book for detailed proof. Cannot both be true Art of Multiprocessor Programming

Art of Multiprocessor Programming © 2003 Herlihy and Shavit Deadlock Free public void lock() { … while (flag[j] && victim == i) {}; Thread blocked only at while loop only if it is the victim One or the other must not be the victim See proof details in book Art of Multiprocessor Programming

Art of Multiprocessor Programming © 2003 Herlihy and Shavit 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; See proof details in book Art of Multiprocessor Programming

The Filter Algorithm for n Threads © 2003 Herlihy and Shavit 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 We now consider two mutual exclusion protocols that work for n threads, where n is greater than 2. The first solution, the \cFilter{} lock, is a direct generalization of the Peterson lock to multiple threads. The second solution, the Bakery lock, is perhaps the simplest and best known $n$-thread solution. The Filter lock creates n-1 ``waiting rooms'', called levels, that a thread must traverse before acquiring the lock. Art of Multiprocessor Programming

Art of Multiprocessor Programming © 2003 Herlihy and Shavit 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 Art of Multiprocessor Programming

Art of Multiprocessor Programming © 2003 Herlihy and Shavit 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; } … Two arrays, one of flags just as in all other algorithms, and one of labels. Art of Multiprocessor Programming

Art of Multiprocessor Programming © 2003 Herlihy and Shavit 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 f t 2 5 4 6 CS Two arrays, one of flags just as in all other algorithms, and one of labels. Art of Multiprocessor Programming

Art of Multiprocessor Programming © 2003 Herlihy and Shavit 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)); } Art of Multiprocessor Programming

Art of Multiprocessor Programming © 2003 Herlihy and Shavit 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 Art of Multiprocessor Programming

Art of Multiprocessor Programming © 2003 Herlihy and Shavit 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 Art of Multiprocessor Programming

Take increasing label (read labels in some arbitrary order) © 2003 Herlihy and Shavit Bakery Algorithm Take increasing label (read labels in some arbitrary order) 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)); } Art of Multiprocessor Programming

Art of Multiprocessor Programming © 2003 Herlihy and Shavit Bakery Algorithm Someone is interested 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)); } Art of Multiprocessor Programming

With lower (label,i) in lexicographic order © 2003 Herlihy and Shavit 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 Art of Multiprocessor Programming

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

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

Art of Multiprocessor Programming © 2003 Herlihy and Shavit No Deadlock There is always one thread with earliest label Ties are impossible (why?) Art of Multiprocessor Programming

Art of Multiprocessor Programming © 2003 Herlihy and Shavit 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)); } Art of Multiprocessor Programming

Art of Multiprocessor Programming © 2003 Herlihy and Shavit Mutual Exclusion Labels are strictly increasing so B must have seen flag[A] == false Art of Multiprocessor Programming

Art of Multiprocessor Programming © 2003 Herlihy and Shavit Mutual Exclusion Labels are strictly increasing so B must have seen flag[A] == false LabelingB  readB(flag[A])  writeA(flag[A])  LabelingA Art of Multiprocessor Programming

Art of Multiprocessor Programming © 2003 Herlihy and Shavit Mutual Exclusion Labels are strictly increasing so B must have seen flag[A] == false LabelingB  readB(flag[A])  writeA(flag[A])  LabelingA Which contradicts the assumption that A has an earlier label Art of Multiprocessor Programming

Art of Multiprocessor Programming © 2003 Herlihy and Shavit Bakery Y232K 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)); } Art of Multiprocessor Programming

Mutex breaks if label[i] overflows © 2003 Herlihy and Shavit Bakery Y232K Bug Mutex breaks if label[i] overflows 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)); } Art of Multiprocessor Programming

Does Overflow Actually Matter? © 2003 Herlihy and Shavit Does Overflow Actually Matter? Yes Y2K 18 January 2038 (Unix time_t rollover) 16-bit counters No 64-bit counters Maybe 32-bit counters Art of Multiprocessor Programming

Art of Multiprocessor Programming © 2003 Herlihy and Shavit Timestamps Label variable is really a timestamp Need ability to Read others’ timestamps Compare them Generate a later timestamp Can we do this without overflow? Art of Multiprocessor Programming

Art of Multiprocessor Programming © 2003 Herlihy and Shavit The Good News One can construct a Wait-free (no mutual exclusion) Concurrent Timestamping system That never overflows Art of Multiprocessor Programming

Art of Multiprocessor Programming © 2003 Herlihy and Shavit The Good News The Bakery Algorithm is Succinct, Elegant, and Fair. Q: So why isn’t it practical? A: Well, you have to read N distinct variables Art of Multiprocessor Programming

Art of Multiprocessor Programming © 2003 Herlihy and Shavit The Good News Bad One can construct a Wait-free (no mutual exclusion) Concurrent Timestamping system That never overflows This part is hard Art of Multiprocessor Programming

Art of Multiprocessor Programming © 2003 Herlihy and Shavit Instead … We construct a Sequential timestamping system Same basic idea But simpler Uses mutex to read & write atomically No good for building locks But useful anyway Art of Multiprocessor Programming

Deep Philosophical Question © 2003 Herlihy and Shavit Deep Philosophical Question The Bakery Algorithm is Succinct, Elegant, and Fair. Q: So why isn’t it practical? A: Well, you have to read N distinct variables Art of Multiprocessor Programming

Art of Multiprocessor Programming © 2003 Herlihy and Shavit           This work is licensed under a Creative Commons Attribution-ShareAlike 2.5 License. You are free: to Share — to copy, distribute and transmit the work to Remix — to adapt the work Under the following conditions: Attribution. You must attribute the work to “The Art of Multiprocessor Programming” (but not in any way that suggests that the authors endorse you or your use of the work). Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under the same, similar or a compatible license. For any reuse or distribution, you must make clear to others the license terms of this work. The best way to do this is with a link to http://creativecommons.org/licenses/by-sa/3.0/. Any of the above conditions can be waived if you get permission from the copyright holder. Nothing in this license impairs or restricts the author's moral rights. Art of Multiprocessor Programming