Avishai Wool lecture 5 - 1 Introduction to Systems Programming Lecture 5 Deadlocks

Avishai Woollecture 5 - 1

Introduction to Systems Programming Lecture 5

Deadlocks


Example of Deadlock

• Dining Philosophers problem

• “pick left, pick right, eat” algorithm

• With some bad luck: – All “pick left”, – All stuck on “pick right”

• This is called Deadlock


When Do Deadlocks Occur

• Deadlocks occur when …

– processes are granted exclusive access to devices– we refer to these devices generally as resources


Resources• Examples of computer resources

– Printers– Tape drives– Entries in OS tables (like PCB entries)– Memory– Database records

• Processes need access to resources in reasonable order

• Access restricted via: critical sections / mutex / semaphore


Resources Usage Pattern• Sequence of events required to use a resource

1. request the resource

2. use the resource

3. release the resource

• Must wait if request is denied– requesting process may be blocked– may fail with error code


Introduction to Deadlocks• Formal definition :

A set of processes is deadlocked if each process in the set is waiting for an event that only another process in the set can cause.

• Usually the event is the release of a currently held resource.

• None of the processes can …– run– release resources– be awakened


Four Conditions for Deadlock

1. Mutual exclusion condition• each resource assigned to 1 process or is available

2. Hold-and-wait condition• process holding resources can request additional resources

3. No preemption condition• previously granted resources cannot forcibly taken away

4. Circular wait condition• must be a circular chain of 2 or more processes

• each is waiting for resource held by next member of the chain


Strategies for Dealing with Deadlock

1. Just ignore the problem altogether.

2. Detection and recovery.

3. Avoidance• careful resource allocation.

4. Prevention • negating one of the four necessary conditions.


Deadlock Detection and Recovery


Modeling Deadlock with Graphs • Process == circle, Resource == square

– resource R assigned to process A– process B is requesting/waiting for resource S– process C and D are in deadlock over resources T and U


A B C

Using Resource Allocation Graph


How deadlock can be avoided

(o) (p) (q)

Scheduling B is delayed


Detection with One Resource of Each Type

• Note the resource ownership and requests• A cycle can be found within the graph, denoting deadlock


Detection with Multiple Resource of Each Type

Data structures needed by deadlock detection algorithm


Deadlock Detection: overview

• Algorithm knows resources, requests

• Needs to determine whether there exists a scheduling order such that all requests can be honored.

• Algorithm is not (necessarily) responsible for scheduling.


Deadlock Detection AlgorithmFor vectors X,Y we say X ≤ Y if Xi ≤ Yi for all i.1. Set all processes as “unmarked”Loop:

2. Find unmarked process i with Ri*≤ A // i can run

3. If found: A A + Ci* ; “mark” process i; // assume i has run, make its resources available

4. Else: If all processes are marked: Success5. Else: System is deadlocked


Example of Deadlock Detection Algorithm

After process 3 runs: A = ( 2, 2, 2, 0)After process 2 runs: A = ( 4, 2, 2, 1)

XX


Recovery from Deadlock (1)

• Recovery through preemption– take a resource from some other process– depends on nature of the resource

• Recovery through rollback– checkpoint a process periodically– use this saved state – restart the process if it is found deadlocked


Recovery from Deadlock (2)

• Recovery through killing processes– crudest but simplest way to break a deadlock– kill one of the processes in the deadlock cycle– the other processes get its resources – choose process that can be rerun from the beginning

None of the deadlock recovery options is very attractive.


Deadlock Avoidance


Deadlock Avoidance

• Can we make decisions one at a time and always avoid deadlock?

• Need some advance knowledge: – Each process has to “declare”, in advance, what

resources, and what is the maximum number of resource units, it will need


Safe and Unsafe States

• The “State” of the system includes– How many resources are allocated to each process– What is the maximum number of resources a process

could request– How many are available

• A state is Safe if– It is not deadlocked– There exists a scheduling order in which all processes

run to completion.


The state in (a) is safe

(a) (b) (c) (d) (e)

Only one resource, 10 copies exist

We could schedule B

After B terminates we could Schedule C


The state in (b) is not safe

(a) (b) (c) (d)

Schedule B


Unsafe != Deadlocked

• If state is safe deadlock can be avoided.

• If state is unsafe not clear– We are making “worst case” assumptions, processes

could use less than their maximum


Banker’s Algorithm (Dijkstra, 1965)

When process requests resource X, 1. Assume the process gets XLoop:

2. Find unmarked process i with Ri*≤ A // i can run

3. If found: A A + Ci* ; mark process i as terminated. // assume i has run, make its resources available

4. Else: System is deadlocked, giving the resource was unsafe


The Banker's Algorithm for a Single Resource

• Three resource allocation states– safe– safe– unsafe

(a) (b) (c)


Is Deadlock Avoidance Practical?

• Banker’s algorithm needs information about future needs (max values for each resource).

• In general OS does not have this information.

• Number of processes varies.

• Resources can “disappear”.


Deadlock Prevention


Idea: invalidate one of the four conditions for deadlock

1. Mutual exclusion condition

2. Hold-and-wait condition

3. No preemption condition

4. Circular wait condition


Attacking the Mutual Exclusion Condition

• Some devices (such as printer) can be spooled– only the printer daemon uses printer resource– thus deadlock for printer eliminated

• Not all devices can be spooled• Principle:

– avoid assigning resource when not absolutely necessary– as few processes as possible actually claim the resource


Attacking the Hold and Wait Condition

• Require processes to request resources before starting– a process never has to wait for what it needs

• Problems– may not know required resources at start of run

– also ties up resources other processes could be using

• Variation: before requesting a new resource, – process must give up all resources

– then request all immediately needed


Attacking the No Preemption Condition

• In general this is not a viable option

• Consider a process given the printer– halfway through its job– now forcibly take away printer– !!??


Attacking the Circular Wait Condition

• Every resource has a unique number

• A process must request resources in increasing number order


Requesting in Order Prevents Deadlock

• 2 resources (i > j) , 2 processes A, B

• Deadlock can only occur if :– A holds i and requests j,

– B holds j and requests i.

• But if they requested resources in order, after A holds i it is not allowed to request j!

• It should have asked for j earlier (and become blocked).


Summary of deadlock prevention

All these options are very restrictive, and not very practical


The Ostrich Algorithm

• Reasonable if – deadlocks occur very rarely.– cost of prevention is high.

• UNIX and Windows takes this approach.

• It is a trade off between – convenience– correctness

General-purpose OSs do not do much towards deadlock detection, recovery, avoidance, or prevention.


A Database example

• A database maintains many tables.

• A transaction might update records in many tables.

• A transaction has to be atomic: – either all records are updated, or none are.


Example

• transfer $1000 from account A to account B

• Read A

• A A – 1000

• Write A

• Read B

• B B + 1000

• Write B


Need to Avoid Inconsistencies

• Lock records before accessing to them – otherwise race conditions possible.

• Database software (Oracle, Sybase, IBM DB2…) provides record locking mechanism.

• Deadlock is certainly possible.


Two-Phase Locking• Phase One

– A transaction locks all records it needs– (no real work done in phase one)

• Phase Two – performing updates– Issuing “commit”– releasing locks


Properties of Two-phase locking

• Deadlock detection by a per-transaction timeout.– Has occasional “false positives”, when disk response

time is bad.

• Deadlock recovery by aborting transactions– An aborted transaction releases all its locks


Why can this work in DB?

• Unlike general OS, a transaction knows which records it will need in advance.

• A transaction can be aborted (rolled back) safely.

• Rollback capability needed for other reasons– Power outage, program crash, may leave DB

inconsistent.


Concepts for review• Deadlock• Conditions for deadlock• Graph models of deadlock• Deadlock detection algorithms• Deadlock avoidance: Safe/Unsafe states• Banker’s algorithm• Deadlock prevention• Spooling• Database transaction• 2-phase locking

Documents

Avishai Wool lecture 5 - 1 Introduction to Systems Programming Lecture 5 Deadlocks