Concurrency: Deadlock ©Magee/Kramer Claus Brabrand University of Aarhus Deadlock Concurrency

Concurrency: Deadlock ©Magee/Kramer Repetition Monitors and Condition Synchronization

Concurrency: Deadlock ©Magee/Kramer Monitors & Condition Synchronization Concepts : monitors: encapsulated data + access procedures + mutual exclusion + condition synchronization + single access procedure active in the monitor nested monitors Models :guarded actions Practice : private data and synchronized methods (exclusion). wait(), notify() and notifyAll() for condition synch. single thread active in the monitor at a time

Concurrency: Deadlock ©Magee/Kramer wait(), notify(), and notifyAll() Thread AThread B wait() notify() Monitor data Wait() causes the thread to exit the monitor, permitting other threads to enter the monitor public final void wait() throws InterruptedException; public final void notify(); public final void notifyAll();

Concurrency: Deadlock ©Magee/Kramer Condition Synchronization (in Java) class CarParkControl { protected int spaces, capacity; synchronized void arrive() throws Int’Exc’ { while (!(spaces>0)) wait(); --spaces; notifyAll(); } synchronized void depart() throws Int’Exc’ { while (!(spaces<capacity)) wait(); ++spaces; notifyAll(); } CONTROL(CAPACITY=4) = SPACES[CAPACITY], SPACES[spaces:0..CAPACITY] = (when(spaces>0) arrive -> SPACES[spaces-1] |when(spaces SPACES[spaces+1]).

Concurrency: Deadlock ©Magee/Kramer Semaphores Semaphores are widely used for dealing with inter-process synchronization in operating systems. Semaphore s : integer var that can take only non-neg. values. sem.p(); // “passern”; decrement (block if counter = 0) sem.v(); // “vrijgeven”; increment counter (allowing one “p”)

Concurrency: Deadlock ©Magee/Kramer LTSA’s (analyse safety) predicts a possible DEADLOCK: This situation is known as the nested monitor problem. Composing potential DEADLOCK States Composed: 28 Transitions: 32 in 60ms Trace to DEADLOCK: get Nested Monitors - Bounded Buffer Model

Concurrency: Deadlock ©Magee/Kramer Chapter 6 Deadlock

Concurrency: Deadlock ©Magee/Kramer Deadlock Concepts : system deadlock (no further progress) 4 necessary & sufficient conditions Models :deadlock - no eligible actions Practice : blocked threads Aim : deadlock avoidance - to design systems where deadlock cannot occur.

Concurrency: Deadlock ©Magee/Kramer Necessary & Sufficient Conditions  Necessary condition:  Sufficient condition:  Necessary & sufficient condition: P necessary for Q: P  Q P sufficient for Q: P  Q P necessary & sufficient for Q: (P  Q)  (P  Q)  P  Q E.g., "Being at university is a necessary condition for attending concurrency" E.g., "Being at university is NOT a sufficient condition for attending concurrency" contrapostion: (P  Q)  (  Q   P)

Concurrency: Deadlock ©Magee/Kramer Deadlock Concepts : system deadlock (no further progress) 4 necessary & sufficient conditions Models :deadlock - no eligible actions Practice : blocked threads Aim : deadlock avoidance - to design systems where deadlock cannot occur.

Concurrency: Deadlock ©Magee/Kramer Deadlock: 4 Necessary and Sufficient Conditions 1. Mutual exclusion cond. (aka. “Serially reusable resources”): the processes involved share resources which they use under mutual exclusion. 2. Hold-and-wait condition (aka. “Incremental acquisition”): processes hold on to resources already allocated to them while waiting to acquire additional resources. 3. No pre-emption condition: once acquired by a process, resources cannot be “pre-empted” (forcibly withdrawn) but are only released voluntarily. 4. Circular-wait condition (aka. “Wait-for cycle”): a circular chain (or cycle) of processes exists such that each process holds a resource which its successor in the cycle is waiting to acquire.

Concurrency: Deadlock ©Magee/Kramer Wait-For Cycle A B C D E Has A awaits B Has B awaits C Has C awaits D Has D awaits E Has E awaits A

Concurrency: Deadlock ©Magee/Kramer 6.1 Deadlock Analysis - Primitive Processes  Deadlocked state is one with no outgoing transitions  In FSP: (modelled by) the STOP process MOVE = (north->(south->MOVE|north->STOP)).  Analysis using LTSA: Trace to DEADLOCK: north Shortest path to DEADLOCK:

Concurrency: Deadlock ©Magee/Kramer Deadlock Analysis - Parallel Composition  In practise, deadlock arises from parallel composition of interacting processes. RESOURCE = (get-> put-> RESOURCE). PRINTER = printer:RESOURCE. SCANNER = scanner:RESOURCE. P = (printer.get-> scanner.get-> copy-> printer.put-> scanner.put-> P). Q = (scanner.get-> printer.get-> copy-> scanner.put-> printer.put-> Q). ||SYS = (p:P || q:Q || {p,q}::PRINTER || {p,q}::SCANNER). printer: RESOURCE get put SYS scanner: RESOURCE get put p:P printer scanner q:Q printer scanner Deadlock trace? Avoidance... P = (x -> y -> P). Q = (y -> x -> Q). ||D = (P || Q). Trace to DEADLOCK: p.printer.get q.scanner.get

Concurrency: Deadlock ©Magee/Kramer Recall the 4 conditions 1. Mutual exclusion cond. (aka. “Serially reusable resources”): the processes involved share resources which they use under mutual exclusion. 2. Hold-and-wait condition (aka. “Incremental acquisition”): processes hold on to resources already allocated to them while waiting to acquire additional resources. 3. No pre-emption condition: once acquired by a process, resources cannot be “pre-empted” (forcibly withdrawn) but are only released voluntarily. 4. Circular-wait condition (aka. “Wait-for cycle”): a circular chain (or cycle) of processes exists such that each process holds a resource which its successor in the cycle is waiting to acquire.

Concurrency: Deadlock ©Magee/Kramer Deadlock Analysis – Avoidance (#1 ?)  Ideas? ...avoid shared resources (used under mutual exclusion)  No shared resources (buy two printers and two scanners) 1. Mutual exclusion cond. (aka. “Serially reusable resources”): the processes involved share resources which they use under mutual exclusion. Deadlock? Scalability? 

Concurrency: Deadlock ©Magee/Kramer Deadlock Analysis – Avoidance (#2 ?)  Only one “mutex” lock for both scanner and printer: Deadlock? Efficiency/Scalability? 2. Hold-and-wait condition (aka. “Incremental acquisition”): processes hold on to resources already allocated to them while waiting to acquire additional resources. LOCK = (acquire-> release-> LOCK). P = (scanner_printer.acquire-> printer.get-> scanner.get-> copy-> scanner.put-> printer.put-> scanner_printer.release-> P). 

Concurrency: Deadlock ©Magee/Kramer Deadlock Analysis – Avoidance (#3 ?)  Force release (e.g., through timeout or arbiter): P = (printer.get-> GETSCANNER), GETSCANNER = (scanner.get-> copy-> printer.put-> scanner.put-> P |timeout -> printer.put-> P). Q = (scanner.get-> GETPRINTER), GETPRINTER = (printer.get-> copy-> printer.put-> scanner.put-> Q |timeout -> scanner.put-> Q). Progress? 3. No pre-emption condition: once acquired by a process, resources cannot be pre-empted (forcibly withdrawn) but are only released voluntarily. Deadlock? 

Concurrency: Deadlock ©Magee/Kramer Deadlock Analysis – Avoidance (#4 ?)  Acquire resources in the same order: Scalability/Progress/…? 4. Circular-wait condition (aka. “Wait-for cycle”): a circular chain (or cycle) of processes exists such that each process holds a resource which its successor in the cycle is waiting to acquire. Deadlock? printer.get-> scanner.get-> copy-> printer.put-> scanner.put-> P). printer.get-> scanner.get-> copy-> printer.put-> scanner.put-> Q). General solution: "sort" resource acquisitions Sort by......what? P = ( Q = (

Concurrency: Deadlock ©Magee/Kramer 6.2 Dining Philosophers Five philosophers sit around a circular table. Each philosopher spends his life alternately thinking and eating. In the centre of the table is a large bowl of spaghetti. A philosopher needs two forks to eat a helping of spaghetti One fork is placed between each pair of philosophers and they agree that each will only use the fork to his immediate right and left.

Concurrency: Deadlock ©Magee/Kramer Dining Philosophers - Model Structure Diagram Each FORK is a shared resource with actions get and put. When hungry, each PHIL must first get his right and left forks before he can start eating.

Concurrency: Deadlock ©Magee/Kramer Dining Philosophers - Model const N = 5 FORK = (get-> put-> FORK). PHIL = (sit -> right.get -> left.get -> eat -> left.put -> right.put -> arise -> PHIL). ||DINING_PHILOSOPHERS = forall [i:0..N-1] (phil[i]:PHIL || FORK). Can this system deadlock? { phil[i].left, phil[((i-1)+N)%N].right }::

Concurrency: Deadlock ©Magee/Kramer Dining Philosophers - Model Analysis This is the situation where all the philosophers become hungry at the same time, sit down at the table and each philosopher picks up the fork to his right. The system can make no further progress since each philosopher is waiting for a left fork held by his neighbour (i.e., a wait-for cycle exists)! Trace to DEADLOCK: phil.0.sit phil.0.right.get phil.1.sit phil.1.right.get phil.2.sit phil.2.right.get phil.3.sit phil.3.right.get phil.4.sit phil.4.right.get

Concurrency: Deadlock ©Magee/Kramer Dining Philosophers Deadlock is easily detected in our model. How easy is it to detect a potential deadlock in an implementation?

Concurrency: Deadlock ©Magee/Kramer Dining Philosophers - Implementation in Java  Forks: shared passive entities (implement as monitors)  Philosophers: active entities (implement as threads)

Concurrency: Deadlock ©Magee/Kramer Dining Philosophers – Fork (Monitor) class Fork { private PhilCanvas display; private boolean taken = false; synchronized void get() throws Int’Exc’ { while (taken) wait(); // cond. synch. (!) taken = true; display.setFork(identity, taken); } synchronized void put() { taken = false; display.setFork(identity, taken); notify(); // cond. synch. (!) } taken encodes the state of the fork FORK = (get-> put-> FORK). FORK = (FORK[FALSE], FORK[taken:B] (when (!taken) get-> FORK[TRUE] |when (taken) put-> FORK[FALSE]). get put  Not needed (if we always "get before put")

Concurrency: Deadlock ©Magee/Kramer Dining Philosophers – Philosopher (Thread) class Philosopher extends Thread { Fork left, right; public void run() { try { while (true) { view.setPhil(identity,view.SIT); sleep(controller.sitTime()); right.get(); view.setPhil(identity,view.GOTRIGHT); sleep(500); // constant pause! left.get(); view.setPhil(identity,view.EATING); sleep(controller.eatTime()); left.put(); right.put(); view.setPhil(identity,view.ARISE); sleep(controller.ariseTime()); } } catch (InterruptedException _) {} } PHIL = (sit -> right.get -> left.get -> eat -> left.put -> right.put -> arise -> PHIL).

Concurrency: Deadlock ©Magee/Kramer Dining Philosophers – Main Applet for (int i=0; i<N; i++) phil[i] = new Philosopher(this, i, fork[(i-1+N)%N], fork[i]); The Applet’s start() method creates (an arrary of) shared Fork monitors…: for (int i=0; i<N; i++) fork[i] = new Fork(display, i); …and (an array of) Philosopher threads (with refs to forks): leftright ||DINING_PHILOSOPHERS = forall [i:0..N-1] (phil[i]:PHIL || { phil[i].left, phil[((i-1)+N)%N].right }::FORK)....and start all Philosopher threads: for (int i=0; i<N; i++) phil[i].start();

Concurrency: Deadlock ©Magee/Kramer Dining Philosophers To ensure deadlock occurs eventually, the slider control may be moved to the left. This reduces the time each philosopher spends thinking and eating. This "speedup" increases the probability of deadlock occurring.

Concurrency: Deadlock ©Magee/Kramer Deadlock-free Philosophers Deadlock can be avoided by ensuring that a wait-for cycle cannot exist. Introduce an asymmetry into definition of philosophers. Use the identity ‘i’ of a philosopher to make even numbered philosophers get their left forks first, odd their right first. How? PHIL[i:0..N-1] = (when (i%2==0) sitdown-> left.get ->...-> PHIL |when (i%2==1) sitdown-> right.get->...-> PHIL). How does this solution compare to the “sort-shared-acquisitions” idea? Other strategies? 1. Mutual exclusion condition 2. Hold-and-wait condition 3. No pre-emption condition 4. Circular-wait condition

Concurrency: Deadlock ©Magee/Kramer Summary  Concepts deadlock (no further progress) 4x necessary and sufficient conditions: 1. Mutual exclusion condition 2. Hold-and-wait condition 3. No pre-emption condition 4. Circular-wait condition  Models no eligible actions (analysis gives shortest path trace)  Practice blocked threads Aim - deadlock avoidance: “Break at least one of the deadlock conditions”.

Concurrency: Deadlock ©Magee/Kramer Claus Brabrand University of Aarhus Program Correctness Concurrency

Concurrency: Deadlock ©Magee/Kramer Outline  Predicates  Induction  Invariants  Correctness  Termination  Monitor Invariants

Concurrency: Deadlock ©Magee/Kramer Predicates (and Invariants)  A predicate is a boolean function: P: VARS -> BOOL, BOOL = {true, false}  Predicate is an assertion about a program’s variables: It may be true or false, depending on the state of the program (i.e., the values of the variables):  DEFINTION: valid predicate (aka. an invariant):  …if it is true every time the program gets there valid program:  …if all of its predicates are valid P(x,y)  x>2  x + y = 10 For state {x=3, y=7}, P(x,y) is true For state {x=2, y=8}, P(x,y) is false E.g.

Concurrency: Deadlock ©Magee/Kramer Induction: ”The Principle of Mathematical Induction”  Example: Proof?! For the example:  n  N: P(n)  n  N : [ … + 2 n = 2 n+1 – 1 ] P(0)  induction stepbase case Principle of mathematical induction: P(n)  [ … + 2 n = 2 n+1 – 1 ] P(i)  P(i+1) 

Concurrency: Deadlock ©Magee/Kramer Example Induction Proof  Example: Base case (i.e. prove: P(0) ) Induction step (i.e. prove: P(i) => P(i+1) ):  Assume the induction hypothesis i.e. we have that P(i):  Now prove P(i+1) i.e. that: P(n)  [ … + 2 n = 2 n+1 – 1 ] P(0)  [ 2 0 = – 1 ]  [ … + 2 i = 2 i+1 – 1 ] [ … + 2 i+1 = 2 (i+1)+1 – 1 ] … + 2 i + 2 i+1 ( … + 2 i ) + 2 i+1 = (2 i+1 – 1) + 2 i+1 == 2*2 i+1 – 1 = 2 (i+1)+1 – 1  I.H.

Concurrency: Deadlock ©Magee/Kramer Invariants: Proof (Predicates + Induction)  Loop invariants (attached to while-loops) Proof: (induction in #loop iterations!): Base case (P(i=0)):  Prove that:INV true having done “0” iterations Induction step (P(i)  P(i+1)):  Assume (induction hypothesis) :INV true having done “i ” iterations  Prove that: INV true having done “i+1” iterations int rest = amount; int n1 = 0, n5 = 0, n10 = 0; while (rest > 0) { // INV: [ ( amount = 10*n10 + 5*n5 + 1*n1 + rest )  ( rest > 0 ) ] if (rest >= 10) { rest = rest – 10; n10 = n10 + 1; } else if (rest >= 5) {rest = rest – 5; n5 = n5 + 1; } else if (rest >= 1) {rest = rest – 1; n1 = n1 + 1; } }

Concurrency: Deadlock ©Magee/Kramer Program Correctness (Example: Money Change)  Decorated program: Invariants should be useful! (not: {2+2 = 4} )! Usually associated with while(/if) statements  Proving the invariants helps us establish program correctness; in this case, that: void change(int amount) { if (amount < 0) abort(); // INV: [ amount >= 0 ] int rest = amount; int n1 = 0, n5 = 0, n10 = 0; while (rest != 0) { // INV: [ ( amount = 10*n10 + 5*n5 + 1*n1 + rest ) ] if (rest >= 10) { rest = rest – 10; n10 = n10 + 1; } else if (rest >= 5) {rest = rest – 5; n5 = n5 + 1; } else if (rest >= 1) {rest = rest – 1; n1 = n1 + 1; } } // INV: [ amount = 10*n10 + 5*n5 + 1*n1 ] output(amount, n10, n5, n1); } amount = 10*n10 + 5*n5 + 1*n1 is calculated if (b) abort(); {  b } Induction: [ P(0)  ( P(i) => P(i+1) ) ] while (b) {I} S {I   b }

Concurrency: Deadlock ©Magee/Kramer Termination (Undecidable in General!)  “if the program terminates, then the result is correct”  However, says nothing about termination!!  In fact; termination is undecidable: Proof (by-contradiction):  Assume decidability (i.e. there exists program, H, such that):  Now construct program P this :  What would H say about this program ( P this )?!? ...hence termination is undecidable (for Turing-complete languages) H(P) = true, if program P terminates = false, if program P doesn’t terminate H(PRG P) =... if (H(P this )) loop(); else terminate(); :-o

Concurrency: Deadlock ©Magee/Kramer (Non-)Termination (cont'd 2 )  "The Book-of-all-Books":  This book contains the titles of all books that do not have a self-reference (i.e. don't contain their title inside)  Q: What about "The Book-of-all-Books" ;  Should it be included or not (in the book of all books)?  "Self-referential paradox" (many guises):  e.g. "This sentence is false" "The Bible" "War and P e ac e" "Concurrency : J ava Models & State Progr a ms"... The Book-of-all-Books

Concurrency: Deadlock ©Magee/Kramer Termination (Sufficient Condition)  “If there’s something (discrete) that gets strictly smaller for every iteration and the loop stops when that something is zero, then the loop terminates”!  That something is called a termination function, T:  T: State -> N (just think of T as an expression, calculating an integer)  Example:  Here, we can use termination function: while (rest > 0) { if (rest >= 10) { rest = rest – 10; n10 = n10 + 1; } else if (rest >= 5) {rest = rest – 5; n5 = n5 + 1; } else if (rest >= 1) {rest = rest – 1; n1 = n1 + 1; } } rest T sufficient for Terminates: T  Terminates

Concurrency: Deadlock ©Magee/Kramer Monitor Invariants  Interleavings make it hard to use invariants!!!  However, monitors: mutual exclusion have (complex) state and state correlations  => invariants can help here: monitor invariants!  {MI} must be true when there’s no thread executing inside… => also when we exit the monitor by invoking wait() !  Monitor invariant: Class Buffer { protected int in, out, count, size; // {monitor invariant (aka. "MI")} synchronized void put(Object o) throws Int’Exc’ { while (!(count<size)) wait();...; notifyAll(); } ( 0 <= count <= size)  ( 0 <= in < size)  ( 0 <= out < size)  ( in = (out + count) % size)

Concurrency: Deadlock ©Magee/Kramer Exercises: -1) Induction proof -2) Factorial -3) Buffer