To develop a description of deadlocks, which prevent sets of concurrent

processes from completing their tasks

To present a number of different methods for preventing or avoiding deadlocks in
a computer system
The Deadlock Problem
A set of blocked processes each holding a resource and waiting to acquire a
resource held by another process in the set
Example
System has 2 disk drives
P1 and P2 each hold one disk drive and each needs another one
Example
semaphores A and B, initialized to 1
P0 P

wait (A); wait(B)

wait (B); wait(A)

Bridge Crossing Example

Traffic only in one direction

Each section of a bridge can be viewed as a resource
If a deadlock occurs, it can be resolved if one car backs up (preempt resources
and rollback)
Several cars may have to be backed up if a deadlock occurs
Starvation is possible
Note – Most OSes do not prevent or deal with deadlocks
System Model
Resource types R1, R2, . . ., Rm
CPU cycles, memory space, I/O devices
Each resource type Ri has Wi instances.
Each process utilizes a resource as follows:
request
use
release

Deadlock Characterization
Deadlock can arise if four conditions hold simultaneously
Mutual exclusion: only one process at a time can use a resource
Hold and wait: a process holding at least one resource is waiting to acquire
additional resources held by other processes
No preemption: a resource can be released only voluntarily by the process
holding it, after that process has completed its task
Circular wait: there exists a set {P0, P1, …, P0} of waiting processes such that
P0 is waiting for a resource that is held by P1, P1 is waiting for a resource that is
held by
P2, …, Pn–1 is waiting for a resource that is held by
Pn, and P0 is waiting for a resource that is held by P0.
n

Resource-Allocation Graph
A set of vertices V and a set of edges E
V is partitioned into two types:
P = {P1, P2, …, Pn}, the set consisting of all the processes in the system
R = {R1, R2, …, Rm}, the set consisting of all resource types in the system
request edge – directed edge P1 ® Rj
assignment edge – directed edge Rj ® Pi

Process

Resource Type with 4 instances

Pi requests instance of Rjn Pi
Rj

Pi is holding an instance of Rj

Pi
Rj

Example of a Resource Allocation Graph

Resource Allocation Graph With A Deadlock

Graph With A Cycle But No Deadlock

Basic Facts
If graph contains no cycles Þ no deadlocknIf graph contains a cycle Þlif only one
instance per resource type, then deadlock
if several instances per resource type, possibility of deadlock
Methods for Handling Deadlocks
Ensure that the system will never enter a deadlock statenAllow the system to
enter a deadlock state and then recovernIgnore the problem and pretend that
deadlocks never occur in the system; used by most operating systems, including
UNIX

Deadlock Prevention
Restrain the ways request can be made
Mutual Exclusion – not required for sharable resources; must hold for
nonsharable resources
Hold and Wait – must guarantee that whenever a process requests a resource,
it does not hold any other resources
Require process to request and be allocated all its resources before it begins
execution, or allow process to request resources only when the process has
none
Low resource utilization; starvation possible

No Preemption –
If a process that is holding some resources requests another resource that
cannot be immediately allocated to it, then all resources currently being held are
released
Preempted resources are added to the list of resources for which the process is
waiting
Process will be restarted only when it can regain its old resources, as well as the
new ones that it is requesting
Circular Wait – impose a total ordering of all resource types, and require that
each process requests resources in an increasing order of enumeration

Deadlock Avoidance
Requires that the system has some additional a priori information
available
Simplest and most useful model requires that each process declare the
maximum number of resources of each type that it may need
The deadlock-avoidance algorithm dynamically examines the resource-allocation
state to ensure that there can never be a circular-wait condition
Resource-allocation state is defined by the number of available and allocated
resources, and the maximum demands of the processes
Safe State
When a process requests an available resource, system must decide if
immediate allocation leaves the system in a safe state
System is in safe state if there exists a sequence <P1, P2, …, Pn> of ALL the
processes is the systems such that for each Pi, the resources that Pi can still
request can be satisfied by currently available resources + resources held by all
the Pj, with j < inThat is:
If Pi resource needs are not immediately available, then Pi can wait until all Pj
have finished
When Pj is finished, Pi can obtain needed resources, execute, return allocated
resources, and terminate
When Pi terminates, Pi +1 can obtain its needed resources, and so on

Basic Facts
nIf a system is in safe state Þ no deadlocksnIf a system is in unsafe state Þ
possibility of deadlocknAvoidance Þ ensure that a system will never enter an
unsafe state.
Safe, Unsafe , Deadlock State
Avoidance algorithms
nSingle instance of a resource type
lUse a resource-allocation graph
nnMultiple instances of a resource type
l Use the banker’s algorithm

Resource-Allocation Graph Scheme

nClaim edge Pi ® Rj indicated that process Pj may request resource Rj;
represented by a dashed linenClaim edge converts to request edge when a
process requests a resourcenRequest edge converted to an assignment edge
when the resource is allocated to the process
nWhen a resource is released by a process, assignment edge reconverts to a
claim edgenResources must be claimed a priori in the system

Resource-Allocation Graph
Unsafe State In Resource-Allocation Graph

Resource-Allocation Graph Algorithm

nSuppose that process Pi requests a resource Rj
nnThe request can be granted only if converting the request edge to an
assignment edge does not result in the formation of a cycle in the resource
allocation graph

Banker’s Algorithm
nMultiple instancesnEach process must a priori claim maximum usenWhen a
process requests a resource it may have to wait nWhen a process gets all its
resources it must return them in a finite amount of time
Data Structures for the Banker’s Algorithm
Let n = number of processes, and m = number of resources types.
nAvailable: Vector of length m. If available [j] = k, there are k instances of
resource type Rj available
nMax: n x m matrix. If Max [i,j] = k, then process Pi may request at most k
instances of resource type RjnAllocation: n x m matrix. If Allocation[i,j] = k then
Pi is currently allocated k instances of RjnNeed: n x m matrix. If Need[i,j] = k,
then Pi may need k more instances of Rj to complete its task

Need [i,j] = Max[i,j] – Allocation [i,j]

Safety Algorithm
1. Let Work and Finish be vectors of length m and n, respectively. Initialize:
Work = Available
Finish [i] = false for i = 0, 1, …, n- 1
2. Find and i such that both:
(a) Finish [i] = false(b) Needi £ Work
If no such i exists, go to step 4
3. Work = Work + Allocationi
Finish[i] = true
go to step 2
4. If Finish [i] == true for all i, then the system is in a safe state

Resource-Request Algorithm for Process Pi

Request = request vector for process Pi. If Requesti [j] = k then process Pi
wants k instances of resource type Rj1. If Requesti £ Needi go to step 2.
Otherwise, raise error condition, since process has exceeded its maximum claim
2. If Requesti £ Available, go to step 3. Otherwise Pi must wait, since
resources are not available
3. Pretend to allocate requested resources to Pi by modifying the state as
follows:
Available = Available – Request;
Allocationi = Allocationi + Requesti;
Needi = Needi – Requesti;
lIf safe Þ the resources are allocated to Pi
lIf unsafe Þ Pi must wait, and the old resource-allocation state is restored

Example of Banker’s Algorithm

n5 processes P0 through P4;
3 resource types:
 A (10 instances), B (5instances), and C (7 instances)
Snapshot at time T0:
Allocation Max
Available ABC A
BC ABC
P0 010 753
332
P1 200 322
P2 302 902
P3 211 222
P4 002 433

nThe content of the matrix Need is defined to be Max – Allocation

Need ABC
P0 7 4 3
P1 1 2 2
P2 6 0 0
P3 0 1 1
P4 4 3 1 nThe system is in a
safe state since the sequence < P1, P3, P4, P2, P0> satisfies safety criteria

Example: P1 Request (1,0,2)

nCheck that Request £ Available (that is, (1,0,2) £ (3,3,2) Þ true
Allocation Need Available
ABC ABC ABC
P0 010 743
230
P1 302 020
P2 301 600
P3 211 011
P4 002 431
nExecuting safety algorithm shows that sequence < P1, P3, P4, P0, P2> satisfies
safety requirement
nCan request for (3,3,0) by P4 be granted?
nCan request for (0,2,0) by P0 be granted?

Deadlock Detection
nAllow system to enter deadlock state nDetection algorithmnRecovery scheme

Single Instance of Each Resource Type

nMaintain wait-for graph
lNodes are processes
lPi ® Pj if Pi is waitingfor PjnPeriodically invoke an algorithm that searches for a
cycle in the graph. If there is a cycle, there exists a deadlock
nAn algorithm to detect a cycle in a graph requires an order of n2 operations,
where n is the number of vertices in the graph
Resource-Allocation Graph and Wait-for Graph

Resource-Allocation Graph Corresponding wait-for

graph
Several Instances of a Resource Type
nAvailable: A vector of length m indicates the number of available resources of
each type.nAllocation: An n x m matrix defines the number of resources of each
type currently allocated to each process.nRequest: An n x m matrix indicates the
current request of each process. If Request [ij] = k, then process Pi is requesting
k more instances of resource type. Rj.

Detection Algorithm
1. Let Work and Finish be vectors of length m and n, respectively Initialize:
(a) Work = Available(b) For i = 1,2, …, n, if Allocationi ¹ 0, then
Finish[i] = false;otherwise, Finish[i] = true2. Find an index i such that both:
(a) Finish[i] == false(b) Requesti £ WorkIf no such i exists, go to step 4
3. Work = Work + Allocationi
Finish[i] = true
go to step 24. If Finish[i] == false, for some i, 1 £ i £ n, then the system is
in deadlock state. Moreover, if Finish[i] == false, then Pi is deadlocked

Algorithm requires an order of O(m x n2) operations to detect whether the

system is in deadlocked state
Example of Detection Algorithm
nFive processes P0 through P4; three resource types
A (7 instances), B (2 instances), and C (6 instances)
nSnapshot at time T0:
Allocation Request
Available
ABC ABC
ABC
P0 010 000 000
P1 200 202
P2 303 000
P3 211 100
P4 002 002
nSequence <P0, P2, P3, P1, P4> will result in Finish[i] = true for all i

nP2 requests an additional instance of type C Request

ABC
P0 000
P1 201
P2 001
P3 100
P4 002
nState of system?
lCan reclaim resources held by process P0, but insufficient resources to fulfill
other processes; requests
lDeadlock exists, consisting of processes P1, P2, P3, and P4

Detection-Algorithm Usage
nWhen, and how often, to invoke depends on:
lHow often a deadlock is likely to occur?
lHow many processes will need to be rolled back?
one for each disjoint cyclenIf detection algorithm is
invoked arbitrarily, there
may be many cycles in the resource graph and so we would not be able to tell
which of the many deadlocked processes “caused” the deadlock
Recovery from Deadlock: Process Termination
nAbort all deadlocked processesnAbort one process at a time until the deadlock
cycle is eliminatednIn which order should we choose to abort?
lPriority of the process
lHow long process has computed, and how much longer to completion
lResources the process has used
lResources process needs to complete
lHow many processes will need to be terminated
lIs process interactive or batch?

Recovery from Deadlock: Resource Preemption

nSelecting a victim – minimize costnRollback – return to some safe state, restart
process for that statenStarvation – same process may always be picked as
victim, include number of rollback in cost factor

I/O Systems
nExplore the structure of an operating system’s I/O subsystem
nDiscuss the principles of I/O hardware and its complexity
nProvide details of the performance aspects of I/O hardware and software
n

I/O Hardware
nIncredible variety of I/O devices
nCommon concepts
lPort
lBus (daisy chain or shared direct access)
lController (host adapter)
nI/O instructions control devices
nDevices have addresses, used by
lDirect I/O instructions
lMemory-mapped I/O

A Typical PC Bus Structure

Device I/O Port Locations on PCs (partial)
Polling
nDetermines state of device
lcommand-ready
lbusy
lErrornBusy-wait cycle to wait for I/O from device
Interrupts
nCPU Interrupt-request line triggered by I/O devicenInterrupt handler receives
interruptsnMaskable to ignore or delay some interruptsnInterrupt vector to
dispatch interrupt to correct handler
lBased on priority
lSome nonmaskablenInterrupt mechanism also used for exceptions

Interrupt-Driven I/O Cycle

Intel Pentium Processor Event-Vector Table
Direct Memory Access
nUsed to avoid programmed I/O for large data movement nRequires DMA
controllernBypasses CPU to transfer data directly between I/O device and
memory
Six Step Process to Perform DMA Transfer
Application I/O Interface
nI/O system calls encapsulate device behaviors in generic classes
nDevice-driver layer hides differences among I/O controllers from kernel
nDevices vary in many dimensions
lCharacter-stream or block
lSequential or random-access
lSharable or dedicated
lSpeed of operation
lread-write, read only, or write only

A Kernel I/O Structure

Characteristics of I/O Devices

Block and Character Devices

nBlock devices include disk drives
lCommands include read, write, seek
lRaw I/O or file-system access
lMemory-mapped file access possiblenCharacter
devices include keyboards,
mice, serial ports
lCommands include get(), put()lLibraries layered on top allow line editing
Network Devices
nVarying enough from block and character to have own interfacenUnix and
Windows NT/9x/2000 include socket interface
lSeparates network protocol from network operation
lIncludes select() functionalitynApproaches vary widely (pipes, FIFOs,
streams, queues, mailboxes)

Clocks and Timers

nProvide current time, elapsed time, timernProgrammable interval timer used for
timings, periodic interruptsnioctl() (on UNIX) covers odd aspects of I/O such
as clocks and timers

Blocking and Nonblocking I/O

nBlocking - process suspended until I/O completed
lEasy to use and understand
lInsufficient for some needsnNonblocking - I/O call returns as much as available
lUser interface, data copy (buffered I/O)
lImplemented via multi-threading
lReturns quickly with count of bytes read or writtennAsynchronous - process runs
while I/O executes
lDifficult to use
lI/O subsystem signals process when I/O completed

Two I/O Methods

 Synchronous Asynchronous

Kernel I/O Subsystem

nScheduling
lSome I/O request ordering via per-device queue
lSome OSs try fairnessnBuffering - store data in memory while transferring
between devices
lTo cope with device speed mismatch
lTo cope with device transfer size mismatch
lTo maintain “copy semantics”

Device-status Table
Sun Enterprise 6000 Device-Transfer Rates

Kernel I/O Subsystem

nCaching - fast memory holding copy of data
lAlways just a copy
lKey to performancenSpooling - hold output for a device
lIf device can serve only one request at a time
li.e., PrintingnDevice reservation - provides exclusive access to a device
lSystem calls for allocation and deallocation
lWatch out for deadlock

Error Handling
nOS can recover from disk read, device unavailable, transient write failuresnMost
return an error number or code when I/O request fails nSystem error logs hold
problem reports
I/O Protection
nUser process may accidentally or purposefully attempt to disrupt normal
operation via illegal I/O instructions
lAll I/O instructions defined to be privileged
lI/O must be performed via system calls
Memory-mapped and I/O port memory locations must be protected too

Use of a System Call to Perform I/O

Kernel Data Structures

nKernel keeps state info for I/O components, including open file tables, network
connections, character device statenMany, many complex data structures to
track buffers, memory allocation, “dirty” blocksnSome use object-oriented
methods and message passing to implement I/O
UNIX I/O Kernel Structure

I/O Requests to Hardware Operations

nConsider reading a file from disk for a process:

lDetermine device holding file

lTranslate name to device representation
lPhysically read data from disk into buffer
lMake data available to requesting process
lReturn control to process
Life Cycle of An I/O Request
STREAMS
nSTREAM – a full-duplex communication channel between a user-level process
and a device in Unix System V and beyond
nnA STREAM consists of:
- STREAM head interfaces with the user process
- driver end interfaces with the device
- zero or more STREAM modules between them.
nEach module contains a read queue and a write queue
nnMessage passing is used to communicate between queues

The STREAMS Structure

Performance
nI/O a major factor in system performance:lDemands CPU to execute
device driver, kernel I/O code
lContext switches due to interrupts
lData copying
lNetwork traffic especially stressful
Intercomputer Communications

Improving Performance
nReduce number of context switches
nReduce data copying
nReduce interrupts by using large transfers, smart controllers, polling
nUse DMA
nBalance CPU, memory, bus, and I/O performance for highest throughput
Device-Functionality Progression