Concurrency: Deadlock ©Magee/Kramer Claus Brabrand brabrand@daimi.au.dk University of Aarhus...

Concurrency: Deadlock ©Magee/Kramer

Claus Brabrand

brabrand@daimi.au.dk

University of Aarhus

Deadlock

Concurrency

Repetition

Monitors and Condition Synchronization

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

wait(), notify(), and notifyAll()

Thread A Thread B

wait()notify()

Monitor

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();

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(N=4) = SPACES[N],SPACES[i:0..N] = (when(i>0) arrive -> SPACES[i-1] |when(i<N) depart -> SPACES[i+1]).

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”)

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

Chapter 6

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.

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.

Wait-For Cycle

Has A awaits B

Has B awaits C

Has C awaits DHas D awaits E

Has E awaits A

6.1 Deadlock Analysis - Primitive Processes

Deadlocked state is one with no outgoing transitions

In FSP: (modelled by) the STOP processMOVE = (north->(south->MOVE|north->STOP)).

Analysis using LTSA:

MOVEnorth north

Trace to DEADLOCK:northnorth

Shortest path to DEADLOCK:

Deadlock Analysis - Parallel Composition

In practise, deadlock arises from parallel composition of interacting processes.

RESOURCE = (get-> put-> 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:RESOURCE || {p,q}::scanner:RESOURCE).

printer:RESOURCEgetput

scanner:RESOURCEgetput

p:Pprinter

scanner

q:Qprinter

scanner

Deadlock trace? Avoidance...

P = (x -> y -> P).Q = (y -> x -> Q).||D = (P || Q).

Trace to DEADLOCK: p.printer.get q.scanner.get

Recall the 4 conditions

once acquired by a process, resources cannot be “pre-empted” (forcibly withdrawn) but are only released voluntarily.

Deadlock Analysis – Avoidance (#1 ?)

Have two printers and two scanners (no shared resources)

Deadlock? Scalability?

Only one “mutex” lock for both scanner and printer:

Deadlock? Efficiency/Scalability?

LOCK = (acquire-> release-> LOCK).

P = (scanner_printer.acquire-> printer.get-> scanner.get-> copy-> scanner.put-> printer.put-> scanner_printer.release-> P).

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?

once acquired by a process, resources cannot be pre-empted (forcibly withdrawn) but are only released voluntarily.

Deadlock?

Acquire resources in the same order:

Scalability/Progress/…?

Deadlock?

P = (printer.get-> scanner.get-> copy-> printer.put-> scanner.put-> P).

Q = (printer.get-> scanner.get-> copy-> printer.put-> scanner.put-> Q).

General solution: “sort resource acquisitions”

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.

Dining Philosophers - Model Structure Diagram

phil[4]:PHIL

phil[1]:PHIL

phil[3]:PHIL

phil[0]:PHIL

phil[2]:PHIL

FORK FORK

lef tright

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.

Dining Philosophers - Model

const N = 5

FORK = (get-> put-> FORK).

PHIL = (sitdown -> 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 }::

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.sitdown phil.0.right.get phil.1.sitdown phil.1.right.get phil.2.sitdown phil.2.right.get phil.3.sitdown phil.3.right.get phil.4.sitdown phil.4.right.get

Dining Philosophers

Deadlock is easily detected in our model.

How easy is it to detect a potential deadlock in an implementation?

Dining Philosophers - Implementation in Java

Forks: shared passive entities (implement as

monitors)Applet

Diners

Thread

Philosopher1 n

PhilCanvas

display

controller

display

Philosophers: active entities (implement as

threads)

Dining Philosophers – Fork (Monitor)

class Fork { private boolean taken = false; private PhilCanvas display; private int identity;

Fork(PhilCanvas disp, int id) { display = disp; identity = id;}

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).

Dining Philosophers – Philosopher (Thread)

class Philosopher extends Thread { public void run() { try { while (true) { view.setPhil(identity,view.SIT); sleep(controller.thinkTime()); 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.standupTime()); } } catch (InterruptedException _) {} }}

PHIL = (sit -> right.get -> left.get -> eat -> left.put -> right.put -> arise -> PHIL).

Dining Philosophers – Main Applet

for (int i=0; i<N; i++) { phil[i] = new Philosopher(this, i, fork[(i-1+N)%N], fork[i]); phil[i].start();}

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 each of which is start()’ed:

left right

||DINING_PHILOSOPHERS = forall [i:0..N-1] (phil[i]:PHIL || { phil[i].left, phil[((i-1)+N)%N].right }::FORK).

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.

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.

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 tothe “sort-shared-acquisitions” idea?

Other strategies?

Summary

Conceptsdeadlock (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

Modelsno eligible actions (analysis gives shortest path trace)

Practiceblocked threads

Aim - deadlock avoidance:

“Break at least one of

the deadlock conditions”.

Claus Brabrand

brabrand@daimi.au.dk

University of Aarhus

Program Correctness

Concurrency

Outline

PredicatesInductionInvariantsCorrectnessTerminationMonitor Invariants

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 therevalid 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 trueFor state {x=2, y=8}, P(x,y) is false

Induction: ”The Principle of Mathematical Induction”

Example:

Proof?!

For the example:

nN: P(n)

nN : [ 20 + 21 + … + 2n = 2n+1 – 1 ]

induction stepbase case

Principle of mathematical induction:

P(n) [ 20 + 21 + … + 2n = 2n+1 – 1 ]

P(i) P(i+1)

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) [ 20 + 21 + … + 2n = 2n+1 – 1 ]

P(0) [ 20 = 20+1 – 1 ]

[ 20 + 21 + … + 2i = 2i+1 – 1 ]

[ 20 + 21 + … + 2i+1 = 2(i+1)+1 – 1 ]

20 + 21 + … + 2i + 2i+1 (20 + 21 + … + 2i) + 2i+1=

(2i+1 – 1) + 2i+1 == 2*2i+1 – 1 = 2(i+1)+1 – 1 I.H.

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

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 }

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 Pthis:

What would H say about this program (Pthis)?!?

H(P) = true, if program P terminates = false, if program P doesn’t terminate

if (H(Pthis)) loop();else terminate();

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

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

T(state) = rest

Monitor Invariants

Interleavings make it hard to use invariants!!! However, monitors:

mutual exclusionhave (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}

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)

</Invariants>

Exercises:-1) Induction proof

-2) Factorial-3) Buffer

Concurrency: Deadlock ©Magee/Kramer Claus Brabrand brabrand@daimi.au.dk University of Aarhus...

Documents

Concurrency: model-based design ©Magee/Kramer Claus Brabrand brabrand@daimi.au.dk University of Aarhus Model-Based Design Concurrency

Concurrency Control · Concurrency Control Chapter 17 . ... Deadlock: Cycle of transactions waiting for locks to be released by each other. Relatively rare schedules lead to deadlock

Chapter 06 OS Concurrency Deadlock and Starvation

Concurrency Solutions and Deadlock CS 111 Operating Systems Peter Reiher

Chapter 6 Concurrency: Deadlock and Starvation

Chapter 6 Concurrency: Deadlock and Starvationhung/cs332/Chap06-E7.pdf · Concurrency: Deadlock and Starvation Operating Systems: Internals and Design Principles ... UNIX provides

1 Concurrency: Deadlock and Starvation Chapter 6

1 Concurrency : Deadlock and Starvation Principles of deadlock –Deadlock is the permanent blocking of a set of processes that either compete for system

DEADLOCK AND ISOLATION LEVELS...•Deadlock prevention and detection •Waits-for graph •My SQL Granular Locking •Concurrency without locking •Optimistic Concurrency Control

1 Chapter 6 Concurrency: Deadlock and Starvation Principals of Deadlock –Deadlock prevention –Deadlock Avoidance –Deadlock detection –An Integrated deadlock

Concurrency ©Magee/Kramer February 05, 2007 Claus Brabrand brabrand@daimi.au.dk University of Aarhus Concurrency Spring 2007

Concurrency: Deadlock and Starvation

Concurrency: Deadlock

Chapter 6 Concurrency: Deadlock and Starvationforsati/cse410s15/Lectures/Chapter 6.pdfEdited by Rana Forsati CSE410 Chapter 6 Concurrency: Deadlock and Starvation ... • Exam review

Efﬁcient, Deterministic and Deadlock-free Concurrency

Chapter 9: Concurrency Control - unibz · Chapter 9: Concurrency Control •Concurrency, Conﬂicts, and Schedules •Locking Based Algorithms •Timestamp Ordering Algorithms •Deadlock

Deadlock - Faculty of Engineering | Imperial College Londonjnm/book/pdf/ch6.pdf · 2015 Concurrency: Deadlock 2 ©Magee/Kramer 2nd Edition Deadlock Concepts: system deadlock: no further

SEMANTIC CONCURRENCY CONTROL AND DEADLOCK ...dspace.pondiuni.edu.in/jspui/bitstream/1/1864/1/103.pdf1.3 Concurrency Control and Deadlock Handling Techniques 4 1.4 Motivation 8 1.5

Claus Brabrand TeaConc 2007 – invited talkJune 25, 2007 Constructive Alignment for Teaching Model-Based Design for Concurrency Claus Brabrand ((( brabrand@daimi.au.dk

Concurrency: Deadlock and Starvation Chapter 6. Goal and approach Deadlock and starvation Underlying principles Solutions? –Prevention –Detection –Avoidance