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

Slides:



Advertisements
Similar presentations
Mutual Exclusion Companion slides for
Advertisements

Mutual Exclusion – SW & HW By Oded Regev. Outline: Short review on the Bakery algorithm Short review on the Bakery algorithm Black & White Algorithm Black.
CSC321 Concurrent Programming: §3 The Mutual Exclusion Problem 1 Section 3 The Mutual Exclusion Problem.
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.
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.
1 Chapter 2 Synchronization Algorithms and Concurrent Programming Gadi Taubenfeld © 2007 Synchronization Algorithms and Concurrent Programming Gadi Taubenfeld.
Chapter 6: 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.
Multiprocessor Synchronization Algorithms ( ) Lecturer: Danny Hendler The Mutual Exclusion problem.
1 Operating Systems, 122 Practical Session 5, Synchronization 1.
Chair of Software Engineering Concurrent Object-Oriented Programming Prof. Dr. Bertrand Meyer Lecture 4: 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.
Mutual Exclusion Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit Modified by Rajeev Alur for CIS 640, Spring.
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.
CPSC 668Set 7: Mutual Exclusion with Read/Write Variables1 CPSC 668 Distributed Algorithms and Systems Fall 2009 Prof. Jennifer Welch.
CPSC 668Set 6: Mutual Exclusion in Shared Memory1 CPSC 668 Distributed Algorithms and Systems Fall 2006 Prof. Jennifer Welch.
It Ain’t the Meat, it’s the Notion Why Theory is Essential to Teaching Concurrent Programming Maurice Herlihy Brown University.
Shared Counters and Parallelism Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit.
Concurrency in Distributed Systems: Mutual exclusion.
Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit Concurrent Skip Lists.
Instructor: Umar KalimNUST Institute of Information Technology Operating Systems Process Synchronization.
02/19/2007CSCI 315 Operating Systems Design1 Process Synchronization Notice: The slides for this lecture have been largely based on those accompanying.
Two-Process Systems TexPoint fonts used in EMF. Read the TexPoint manual before you delete this box.: A A AA Companion slides for Distributed Computing.
Operating Systems CSE 411 CPU Management Oct Lecture 13 Instructor: Bhuvan Urgaonkar.
Multicore Programming
Manifold Protocols TexPoint fonts used in EMF. Read the TexPoint manual before you delete this box.: A A AA Companion slides for Distributed Computing.
Mutual Exclusion Presented by: Rohan Sen (Distributed Algorithms Ch. 10)
28/10/1999POS-A1 The Synchronization Problem Synchronization problems occur because –multiple processes or threads want to share data; –the executions.
Process Synchronization Continued 7.2 Critical-Section Problem 7.3 Synchronization Hardware 7.4 Semaphores.
Mutual Exclusion Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit.
Operating Systems ECE344 Ashvin Goel ECE University of Toronto Mutual Exclusion.
THIRD PART Algorithms for Concurrent Distributed Systems: The Mutual Exclusion problem.
DISTRIBUTED ALGORITHMS AND SYSTEMS Spring 2014 Prof. Jennifer Welch CSCE
Mutual Exclusion Using Atomic Registers Lecturer: Netanel Dahan Instructor: Prof. Yehuda Afek B.Sc. Seminar on Distributed Computation Tel-Aviv University.
Mutual Exclusion Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit.
Chapter 6 – Process Synchronisation (Pgs 225 – 267)
1 Concurrent Processes. 2 Cooperating Processes  Operating systems allow for the creation and concurrent execution of multiple processes  concurrency.
Mutual Exclusion Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit.
CIS 842: Specification and Verification of Reactive Systems Lecture INTRO-Examples: Simple BIR-Lite Examples Copyright 2004, Matt Dwyer, John Hatcliff,
Operating Systems CMPSC 473 Mutual Exclusion Lecture 11: October 5, 2010 Instructor: Bhuvan Urgaonkar.
CSCI-375 Operating Systems Lecture Note: Many slides and/or pictures in the following are adapted from: slides ©2005 Silberschatz, Galvin, and Gagne Some.
Monitors and Blocking Synchronization Dalia Cohn Alperovich Based on “The Art of Multiprocessor Programming” by Herlihy & Shavit, chapter 8.
Concurrent Queues Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit.
Multiprocessor Architecture Basics Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit.
Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit Concurrent Skip Lists.
“Towards Self Stabilizing Wait Free Shared Memory Objects” By:  Hopeman  Tsigas  Paptriantafilou Presented By: Sumit Sukhramani Kent State University.
The Relative Power of Synchronization Operations Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit.
6.852: Distributed Algorithms Spring, 2008 Class 14.
CSC Multiprocessor Programming, Spring, 2012 Chapter 10 – Avoiding Liveness Hazards Dr. Dale E. Parson, week 11.
Mutual Exclusion. Art of Multiprocessor Programming 2 Mutual Exclusion We will clarify our understanding of mutual exclusion We will also show you how.
Synchronization Questions answered in this lecture: Why is synchronization necessary? What are race conditions, critical sections, and atomic operations?
Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit Concurrent Skip Lists.
Mutual Exclusion Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit.
CSCE 668 DISTRIBUTED ALGORITHMS AND SYSTEMS
Concurrent Objects Companion slides for
Mutual Exclusion Companion slides for
Mutual Exclusion Companion slides for
Simulations and Reductions
Mutual Exclusion Companion slides for
CSCE 668 DISTRIBUTED ALGORITHMS AND SYSTEMS
Chapter 6: Synchronization Tools
Distributed Computing
CSE 542: Operating Systems
Mutual Exclusion Modified from Companion slides for
Presentation transcript:

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

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

Mutual Exclusion In his 1965 paper E. W. Dijkstra wrote: "Given in this paper is a solution to a problem which, to the knowledge of the author, has been an open question since at least 1962, irrespective of the solvability. [...] Although the setting of the problem might seem somewhat academic at first, the author trusts that anyone familiar with the logical problems that arise in computer coupling will appreciate the significance of the fact that this problem indeed can be solved." Art of Multiprocessor Programming 3

4 Mutual Exclusion Formal problem definitions Solutions for 2 threads Solutions for n threads Fair solutions Inherent costs

Art of Multiprocessor Programming 5 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 6 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 7 “Absolute, true and mathematical time, of itself and from its own nature, flows equably without relation to anything external.” (I. Newton, 1689) “Time is, like, Nature’s way of making sure that everything doesn’t happen all at once.” (Anonymous, circa 1968) Time time

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

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

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

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

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

Art of Multiprocessor Programming 13 time Thread A Concurrency

Art of Multiprocessor Programming 14 time Thread A Thread B Concurrency

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

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

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

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

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

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

Art of Multiprocessor Programming 21 Precedence Ordering Remark: A 0  B 0 is just like saying –1066 AD  1492 AD, –Middle Ages  Renaissance, Oh wait, –what about this week vs this month?

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

Art of Multiprocessor Programming 23 Partial Orders (you may know this already) 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

Art of Multiprocessor Programming 24 Total Orders (you may know this already) Also –Irreflexive –Antisymmetric –Transitive Plus: for every distinct A, B, –Either A  B or B  A

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

Art of Multiprocessor Programming 26 Goal: Implement a Shared 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 27 Locks (Mutual Exclusion) public interface Lock { public void lock(); public void unlock(); }

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

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

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

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

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 = temp + 1; } finally { lock.unlock(); } return temp; }} acquire Lock

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 = temp + 1; } finally { lock.unlock(); } return temp; }} Release lock (no matter what)

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 = temp + 1; } finally { lock.unlock(); } return temp; }} Critical section

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

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

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 j’s m-th execution Then either – or

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 CS i k  CS j m

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 CS j m  CS i k

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

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

Art of Multiprocessor Programming 42 Two-Thread vs n -Thread Solutions Two-thread solutions first –Illustrate most basic ideas –Fits on one slide Then n-Thread solutions Warning: –The following code examples use Java syntax, but they may not work in Java –Read as pseudocode

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

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 Henceforth: i is current thread, j is other thread

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

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]) {} } Set my flag

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

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

Art of Multiprocessor Programming 49 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]) {} }

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

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

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

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

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

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

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

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

Art of Multiprocessor Programming 58 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]){}

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

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() {} } Let other go first

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() {} } Wait for permission

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

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

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

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; } Announce I’m interested

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 Defer to other

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 Wait while other interested & I’m the victim

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 No longer interested

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

Art of Multiprocessor Programming 70 Deadlock Free Thread blocked –only at while loop –only if it is the victim One or the other must not be the victim public void lock() { … while (flag[j] && victim == i) {};

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

N Threads / /in/photolist-4HyaDs- 5X5CZo-4yxtzZ-5kRXkQ-75HWGx- 4VtMxv-kvmiST-5pZ6jX-atsnpE- 377WsS-7yuiDt-vG2zS-9YG77U- 8Bd19s-abJzg-paW61k-7X6nmx- 71L1BY-dLYkqF-eAiavm-8ZaRo6- 73p4V4-azR9hu-2DcKgr-np4xpD- 9eatVx-9VTcv-iFkAnK-aoGebU- owET4C-5cBhRM-65pou2-71yQXW- 9f2BhS-6yD5Db-4L37e5-dGYDU7- yLqnw-gt8HUv-23xZ3-aRA5cP- 5ksfMt-73QafP-8B9UPP-axUn52- m2CrcF-8Bd2J1-711QvD-6hHVkw- ceFaRLehttps:// / /in/photolist-4HyaDs- 5X5CZo-4yxtzZ-5kRXkQ-75HWGx- 4VtMxv-kvmiST-5pZ6jX-atsnpE- 377WsS-7yuiDt-vG2zS-9YG77U- 8Bd19s-abJzg-paW61k-7X6nmx- 71L1BY-dLYkqF-eAiavm-8ZaRo6- 73p4V4-azR9hu-2DcKgr-np4xpD- 9eatVx-9VTcv-iFkAnK-aoGebU- owET4C-5cBhRM-65pou2-71yQXW- 9f2BhS-6yD5Db-4L37e5-dGYDU7- yLqnw-gt8HUv-23xZ3-aRA5cP- 5ksfMt-73QafP-8B9UPP-axUn52- m2CrcF-8Bd2J1-711QvD-6hHVkw- ceFaRLe

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

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 = 0; i < n; i++) { level[i] = 0; }} … } level victim n Thread 2 at level 4 0 4

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; }}

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); // busy wait }} public void release(int i) { level[i] = 0; }} Filter Announce intention to enter level L

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

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 Wait as long as someone else is at same or higher level, and I’m designated victim

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 Thread enters level L when it completes the loop

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

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

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

Art of Multiprocessor Programming 83 From the Code (1) write B (level[B]=L)  write B (victim[L]=B) 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) {}; }}

Art of Multiprocessor Programming 84 From the Code (2) write A (victim[L]=A)  read A (level[B]) 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) {}; }}

Art of Multiprocessor Programming 85 By Assumption By assumption, A is the last thread to write victim[L] (3) write B (victim[L]=B)  write A (victim[L]=A)

Art of Multiprocessor Programming 86 Combining Observations (1) write B (level[B]=L)  write B (victim[L]=B) (3) write B (victim[L]=B)  write A (victim[L]=A) (2) write A (victim[L]=A)  read A (level[B])

Art of Multiprocessor Programming 87 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) {}; }} Combining Observations (1) write B (level[B]=L)  write B (victim[L]=B) (3) write B (victim[L]=B)  write A (victim[L]=A) (2) write A (victim[L]=A)  read A (level[B])

Art of Multiprocessor Programming 88 Combining Observations (1) write B (level[B]=L)  write B (victim[L]=B) (3) write B (victim[L]=B)  write A (victim[L]=A) (2) write A (victim[L]=A)  read A (level[B]) Thus, A reads level[B] ≥ L, A was last to write victim[L], so it could not have entered level L!

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

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

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

Art of Multiprocessor Programming 92 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+r A’s k-th critical section precedes B’s (j+r)-th critical section B cannot overtake A by more than r times First-come-first-served: r = 0. DEF: r-Bounded Waiting

Art of Multiprocessor Programming 93 Fairness Again Filter Lock satisfies properties: –No one starves –But very weak fairness Not r-bounded for any r! –That’s pretty lame…

Art of Multiprocessor Programming 94 Bakery Algorithm (Lamport) 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 95 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; } …

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

Art of Multiprocessor Programming 97 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 98 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 99 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 100 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)

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

Art of Multiprocessor Programming 102 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 103 Bakery Algorithm class Bakery implements Lock { … public void unlock() { flag[i] = false; }

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

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

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

Art of Multiprocessor Programming 107 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 108 Mutual Exclusion Labels are strictly increasing so B must have seen flag[A] == false

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

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

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

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

Art of Multiprocessor Programming 113 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 114 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 115 One can construct a timestamping system that is... –Wait-free (no mutual exclusion) –Concurrent –Free of overflows The Good News

Art of Multiprocessor Programming 116 One can construct a timestamping system that is... –Wait-free (no mutual exclusion) –Concurrent –Free of overflows The Good News This part is hard Bad

Art of Multiprocessor Programming 117 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 118 Precedence Graphs 0123 Timestamps form directed graph Edge x to y –Means x is later timestamp –We say x dominates y

Art of Multiprocessor Programming 119 Unbounded Counter Precedence Graph 0123 Timestamping = move tokens on graph Atomically –read others’ tokens –move mine Ignore tie-breaking for now

Art of Multiprocessor Programming 120 Unbounded Counter Precedence Graph 0123

Art of Multiprocessor Programming 121 Unbounded Counter Precedence Graph 0123 takes 0 takes 1 takes 2

Art of Multiprocessor Programming 122 Two-Thread Bounded Precedence Graph 0 12

Art of Multiprocessor Programming 123 Two-Thread Bounded Precedence Graph 0 12

Art of Multiprocessor Programming 124 Two-Thread Bounded Precedence Graph 0 12

Art of Multiprocessor Programming 125 Two-Thread Bounded Precedence Graph 0 12

Art of Multiprocessor Programming 126 Two-Thread Bounded Precedence Graph T and so on …

Art of Multiprocessor Programming 127 Three-Thread Bounded Precedence Graph? 1203

Art of Multiprocessor Programming 128 Three-Thread Bounded Precedence Graph? 1203 Not clear what to do if one thread gets stuck

Art of Multiprocessor Programming 129 Graph Composition Replace each vertex with a copy of the graph T 3 =T 2 *T 2

Art of Multiprocessor Programming 130 Three-Thread Bounded Precedence Graph T

Art of Multiprocessor Programming 131 Three-Thread Bounded Precedence Graph T <<

Art of Multiprocessor Programming 132 Three-Thread Bounded Precedence Graph T and so on…

Art of Multiprocessor Programming 133 In General T k = T 2 * T k-1 K threads need 3 k nodes label size = Log 2 (3 k ) = 2n

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

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

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

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

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

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

Art of Multiprocessor Programming 141 Theorem (First 2-Threads) 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Art of Multiprocessor Programming 159 This work is licensed under a Creative Commons Attribution- ShareAlike 2.5 License.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 – 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.