Uploaded by chansa musondah

08 Deadlock

advertisement
MULUNGUSHI UNIVERSITY
Pursing the frontiers of Knowledge
CENTRE FOR ICT EDUCATION
___________________
Operating Systems
___________________
Mr A. Zimba
Operating Systems
DEADLOCK
Operating Systems
DEADLOCK

DEADLOCK

SEVEN CASES OF DEADLOCK

FOUR NECESSARY CONDITIONS FOR DEADLOCKS

RESOURCE-ALLOCATION GRAPH

DEADLOCK PREVENTION

DEADLOCK AVOIDANCE

DEADLOCK DETECTION

DEADLOCK RECOVERY

The Ostrich Algorithm
DEADLOCK

Permanent blocking of a set of processes
competing for resources
 Situation where a process is waiting for an event
that will never occur
 Deadlocks may involve:Consumable resources
are destroyed when acquired by processes
eg. interrupts, messages, information in
I/O buffers
Reusable resources
not depleted or destroyed by use
Operating Systems
DEADLOCK
3
DEADLOCK (cont.)

Deadlock Examples
 Traffic deadlock
 Deadlock in stairway system

Related Problem: Starvation (indefinite
postponement or indefinite blocking)
 System is not deadlocked but at least one process is
indefinitely postponed
 Occurs because of biases in system’s policies of
scheduling resources
 Solved by using the Aging technique
 prevents indefinite postponement by increasing process’s
priority as it waits for resource
Operating Systems
DEADLOCK
4
A classic case of traffic deadlock on four one-way streets.
This is “gridlock,” where no vehicles can move forward to
clear the traffic jam
Operating Systems
DEADLOCK
5
SEVEN CASES OF DEADLOCK
Case 1: Deadlocks on File Requests

These two processes, shown as circles, are each waiting
for a resource, shown as rectangles, that has already been
allocated to the other process, thus creating a deadlock.
Operating Systems
DEADLOCK
6
cont./
Case 2: Deadlocks in Databases
A race introduces the
element of chance, an
element that’s totally
unacceptable in
database management.
The integrity of the
database must be
upheld.

P1 finishes first and wins the race but its version of the record will
soon be overwritten by P2. Regardless of which process wins the
race, the final version of the data will be incorrect.
Operating Systems
DEADLOCK
7
cont./
Case 3: Deadlocks in Dedicated Device Allocation


P1 and P2, both programs need two DVD drivers to copy files
from one disc to another.
The following sequence transpires:
 1. P1 requests drive 1 and gets it.
 2. P2 requests drive 2 and gets it.
 3. P1 requests drive 2 but is blocked.
 4. P2 requests drive 1 but is blocked.

Neither job can continue because each is waiting for the
other to finish and release its drive—an event that will never
occur.
Operating Systems
DEADLOCK
8
cont./
Case 4: Deadlocks in Multiple Device Allocation

Three processes, shown as circles, are each waiting for a
device that has already been allocated to another process,
thus creating a deadlock.
Operating Systems
DEADLOCK
9
cont./
Case 5: Deadlocks in Spooling


The spooler accepts output from several users and acts as a
temporary storage (buffer) area for all output until the printer
is ready to accept it.
This process is called spooling.
 If the printer needs all of a job’s output before it will begin printing (e.g. all
pages),
 but the spooling system fills the available space with only partially
completed output,

 then a deadlock can occur.
 spooler is full of partially completed output, no other pages can be
accepted,
 but none of the jobs can be printed out because the printer only accepts
completed output files
Operating Systems
DEADLOCK
10
cont./
Case 6: Deadlocks in a Network

Case 6, deadlocked network flow. Notice that only two nodes, C1 and C2,
have buffers. Each circle represents a node and each line represents a
communication path. The arrows indicate the direction of data flow.
Operating Systems
DEADLOCK
11
cont./
Case 7: Deadlocks in Disk Sharing

Two processes are each waiting for an I/O request to be filled: one at
track 20 and one at track 310. But by the time the read/write arm reaches
one track, a competing command for the other track has been issued, so
neither command is satisfied and livelock occurs.
Operating Systems
DEADLOCK
12
FOUR NECESSARY CONDITIONS FOR
DEADLOCKS

Mutual exclusion
 Mutual exclusion, the act of allowing only one process to have
access to a resource, is the first condition for deadlock.

Wait for or Hold & wait (Resource Holding)
A process is holding one or more resources while
waiting for others

No preemption
Resources cannot be preempted

Circular wait
 These three lead to the fourth condition of circular wait in which
each process involved in the impasse is waiting for another to
voluntarily release the resource.
Operating Systems
DEADLOCK
13
cont./

When a deadlock occurs, all four conditions are
present, though the opposite is not true—the
presence of all four conditions does not always
lead to deadlock.

Each of these four conditions is necessary for
the operating system to work smoothly. None of
them can be removed easily without causing the
system’s overall functioning to suffer.
Operating Systems
DEADLOCK
14
Modeling Deadlocks


Holt showed how the four conditions can be modeled using directed
graphs.
These graphs use two kinds of symbols:
 Processes (P) represented by circles and Resources (R) represented by squares.

A solid arrow from a resource to a process means that the process is
holding that resource.

A dashed line with an arrow from a process to a resource means that the
process is waiting for that resource.

The direction of the arrow indicates the flow.

If there’s a cycle in the graph then there’s a deadlock involving the
processes and the resources in the cycle.
Operating Systems
DEADLOCK
15
cont./
 In (a), Resource 1 is being held by Process 1 and Resource 2 is held by Process 2
in a system that is not deadlocked.
 In (b), Process 1 requests Resource 2 but doesn’t release Resource 1, and Process
2 does the same — creating a deadlock. (If one process released its resource, the
deadlock would be resolved.)
Operating Systems
DEADLOCK
16
RESOURCE-ALLOCATION GRAPH

Consists of a set of vertices V and a set of edges
E
 V is partitioned into:
P = (P1,P2,…,Pn); the set of all processes in the
system
R = (R1,R2,…Rm); the set of all resource types in the
system

E is partitioned into:
Request Edge: Pi  Rj represents a request for Rj
from Pi
Assignment Edge: Rj  Pi represents an allocation of
Rj to Pi
Operating Systems
DEADLOCK
17
RESOURCE-ALLOCATION GRAPH (cont.)

Notation:
Large circles
 Represent processes
Rectangles
 Represent types of identical resources
Small circles drawn inside rectangles
 Indicate separate identical resources of each type
Rules:
 No cycles mean no deadlock
 One or more cycles
Deadlock if one instance per resource type
May be if several instances per resource type
Operating Systems
DEADLOCK
18
RESOURCE ALLOCATION GRAPH WITH
NO CYCLES
Operating Systems
DEADLOCK
19
RESOURCE ALLOCATION GRAPH WITH
NO CYCLES
Operating Systems
DEADLOCK
20
RESOURCE ALLOCATION GRAPH WITH
A CYCLE
Operating Systems
DEADLOCK
21
RESOURCE ALLOCATION GRAPH WITH
A CYCLE
Operating Systems
DEADLOCK
22
DEADLOCK PREVENTION


Removes any possibility of deadlock
Approach (Havender, 1968): To ensure that at
least 1 of the necessary conditions cannot
hold
 Often results in poor resource utilization
Mutual Exclusion
In general, it's not possible to prevent deadlocks
by denying mutual exclusion condition, e.g.
non-sharable resources eg. Printers
files: exclusive write access
Operating Systems
DEADLOCK
23
DEADLOCK PREVENTION (cont.)
Hold & Wait
Each process to request & be allocated all of its
required resources before execution
Disadvantages :
1. Low resource utilization
 2. Starvation is possible
 3. Process needs to know its resource need
in advance
Operating Systems
DEADLOCK
24
DEADLOCK PREVENTION (cont.)
No Preemption
resources currently held by a process can be
preempted
only suitable to resources whose states
can be easily saved & restored later
high overhead
prone to starvation
Circular Wait
Assign a unique integer to each resource type;
processes must request resources in linear
ascending order
Inefficient & difficult to implement
If jobs need resources in different orders,
resources are held but unused
Operating Systems
DEADLOCK
Not user-friendly
25
DEADLOCK AVOIDANCE
Not preconditioned to remove all possibility of
deadlock, but deadlocks are avoided by carefully
allocating resources
Analysis of each new resource request and
granting it only if deadlock is not possible
Each process must declare the maximum number
of resources of each type it needs
A deadlock avoidance algorithm dynamically
examines the resource allocation state to ensure
of no circular wait condition
Operating Systems
DEADLOCK
26
DEADLOCK AVOIDANCE (cont.)
A state is safe if the
system can guarantee
that all current
processes can
complete their work
within a finite time
An unsafe state does
NOT imply the
(eventual) existence of
a deadlock. It implies
that some sequence
could lead to deadlock.
Operating Systems
DEADLOCK
27
DEADLOCK AVOIDANCE (cont.)
A system is in safe state if there exists a safe
sequence <P1,P2,…,Pn> where:
for each Pi, the additional resources requested by
Pi can be satisfied by currently available
resources + resources held by all the Pj, where j 
i
A system in safe state implies no deadlock
A system in unsafe state implies a possibility of
deadlock
Operating Systems
DEADLOCK
28
DEADLOCK DETECTION

Determining that a deadlock exists and
identifying the processes and resources
involved
 Generally determine if a circular wait exists
 Deadlock recovery is required to break
deadlock
Operating Systems
DEADLOCK
29
DEADLOCK RECOVERY

The breaking of deadlock by removing one or
more of the necessary conditions
 Difficult because:
may not be clear that the system has become
deadlocked in the first place
very difficult to suspend process, remove it, and
resume it later
involves considerable overhead
could involve an enormous amount of work being
redone
Operating Systems
DEADLOCK
30
DEADLOCK RECOVERY

PROCESS TERMINATION
Kill all deadlocked processes
Kill one process at a time until no more deadlock
Factors for process selection:
1. Process priority
2. Time the process has computed & will compute
before finishing its task
3. Number & type of resources process has used &
will use before completing its task
4. Number of processes needed to be terminated
5. Type of the process - Interactive or Batch
Operating Systems
DEADLOCK
31
DEADLOCK RECOVERY (cont.)

RESOURCE PREEMPTION
Issues to be considered:
– Victim Selection
– Minimize cost
– Rollback
– Starvation
Operating Systems
DEADLOCK
32
The Ostrich Algorithm

Pretends deadlock does not exist
 Used by UNIX
 Example
process table contains finite no. of slots (say 100)
assume 10 running programs each needs to
create 12 (sub)processes
table is exhausted after each program has created
9 processes
Operating Systems
DEADLOCK
33
Download