Download Report

4/1/2015
Preview





Deadlocks
Deadlocks
Resources for a Process
Deadlock Condition
Resource Allocation Graph
Four Strategies for Dealing Deadlock



CS450 Operating System, Spring 2015
Dr. Sang-Eon Park
1
Deadlocks


In multiprogramming environment, several
processes may complete for a finite number of
resources.
In concurrent programming, a deadlock is a
situation in which two or more competing actions
are each waiting for the other to finish, and thus
neither ever does.
Deadlocks between processes can be occurred
since limitation of resources which must be
shared.
CS450 Operating System, Spring 2015
Dr. Sang-Eon Park
2
Deadlocks
Deadlock is a common problem in multiprocessing systems,
parallel computing and distributed systems, where software
and hardware locks are used to handle shared resources
and implement process synchronization.
In a transactional database, a deadlock happens when two
processes each within its own transaction updates two rows
of information but in the opposite order. For example,
process A updates row 1 then row 2 in the exact timeframe
that process B updates row 2 then row 1. Process A can't
finish updating row 2 until process B is finished, but process
B cannot finish updating row 1 until process A is finished.
Row 1
Hold by process 1
Row 2
Hold by process 2
Row 3
Row 4
Row 5
…
Database transaction
CS450 Operating System, Spring 2015
Dr. Sang-Eon Park
3
Deadlocks
CS450 Operating System, Spring 2015
Dr. Sang-Eon Park
Deadlocks

P1
R2
P1
R2
P1
R2
There are two processes P1, P2 working on their
job and , and two resource R1 and R2. Both P1
and P2 need R1 and R2 to finish their job.


R1
a)
P2
4
R1
P2
b)
CS450 Operating System, Spring 2015
Dr. Sang-Eon Park
R1

P2

c)
5
T1: P1 request R1 and granted
T1: P2 request R2 and granted
T2: P1 request R2 without releasing R1. But, since R2 is
hold by P2, P1 become waiting (block) state waiting for
R2 which is granted to P2
T3: P2 request R1 but it is not released by P1 yet, P2 go
to blocked state. P1 and P2 will be blocked forever.
CS450 Operating System, Spring 2015
Dr. Sang-Eon Park
6
1
4/1/2015
Deadlocks
Resources for a Process

Preemptive resources –
Resources that can be taken away from the
process currently own it without ill effect. Ex)
Memory

Non-preemptive resources –
Resources that cannot be taken away from the
process currently own it until the process finish
using the resource and release it. Ex) CD
recorder, Printer
Deadlock
No Deadlock
CS450 Operating System, Spring 2015
Dr. Sang-Eon Park
7
The sequence of event for using a resources
2.
3.

Request the resource
Use the resource
Release the resource

If a resource is not available when it is
requested, the requesting process might
be




Blocked and awakened when it is available
Wait a little while and try again
CS450 Operating System, Spring 2015
Dr. Sang-Eon Park
9
Implementation of Resource request,
use and release
CS450 Operating System, Spring 2015
Dr. Sang-Eon Park
10
Ex)
 Lets there are two processes P1, P2
working on their job and , and two
resource R1 and R2.
 Both P1 and P2 need R1 and R2 to finish
their job.
 Each resource is associated with a
semaphore.
semaphore R1;
semaphore R2;
void process_P()
{
down(&R1);
down(&R2);
use_both_resource();
up(&R2);
up(&R1);
}
CS450 Operating System, Spring 2015
Dr. Sang-Eon Park
How to implement a request of resource is highly
system dependent.
But usually, the request and release of resources
are system calls. (ex. request and release
device, open and close file, allocate and
deallocate memory system calls).
Request and release can be accomplished
through down and up operations on
semaphores.
If a resource is already allocated to a process,
the process request the resource is added to a
queue of waiting for this resource.
Implementation of Resource request,
use and release
Associate a semaphore with each resource.
semaphore R1;
void process_P()
{
down(&R1);
use_resource ();
up(&R1);
}
8
Implementation of Resource request,
use and release
Sequence for Resource Use
1.
CS450 Operating System, Spring 2015
Dr. Sang-Eon Park
11
CS450 Operating System, Spring 2015
Dr. Sang-Eon Park
12
2
4/1/2015
Implementation of Resource request,
use and release
Implementation of Resource request,
use and release
Case 1)
semaphore R1;
semaphore R2;
void process_P1()
{
down(&R1);
down(&R2);
use_both_resource();
up(&R2);
up(&R1);
}
Case 2)
semaphore R1;
semaphore R2;
void process_P1()
{
down(&R1);
down(&R2);
use_both_resource();
up(&R2);
up(&R1);
}
void process_P2()
{
down(&R1);
down(&R2);
use_both_resource();
up(&R2);
up(&R1);
}
CS450 Operating System, Spring 2015
Dr. Sang-Eon Park
13
Deadlock Condition

1.
2.
3.
4.






15
Resource-Allocation Graph
CS450 Operating System, Spring 2015
Dr. Sang-Eon Park
CS450 Operating System, Spring 2015
Dr. Sang-Eon Park
14
Resource Allocation Graph
A deadlock situation can arise if and only
if the following four conditions hold
simultaneously in a system.
Mutual exclusion
Hold and wait
No preemption
Circular wait
CS450 Operating System, Spring 2015
Dr. Sang-Eon Park
void process_P2()
{
down(&R2);
down(&R1);
use_both_resource();
up(&R1);
up(&R2);
}
This graph consists of a set of vertices V and a
set of edges E.
The set of vertices V is partitioned into two types
P = {P1, P2, …, Pn}= set of processes and
R = {R1, R2, …, Rm} = set of resources
Edge from a process to a resource P → R denote
process P request resource R and currently
waiting
Edge from a resource to a process R → P denote
resource R is currently held by process P
CS450 Operating System, Spring 2015
Dr. Sang-Eon Park
16
Deadlock Example
17
CS450 Operating System, Spring 2015
Dr. Sang-Eon Park
18
3
4/1/2015
Deadlock Example
Four Strategies for Dealing Deadlock




CS450 Operating System, Spring 2015
Dr. Sang-Eon Park
19


CS450 Operating System, Spring 2015
Dr. Sang-Eon Park
20
Deadlock Detection with One Resource
of Each Type
Deadlock Detection and Recovery

Just ignore
Detection and Recover
Dynamic Avoidance by careful allocation
Prevention – by negating one of the four
conditions necessary to cause deadlock
Recovery through preemption
Recovery through killing processes
Recovery through Rollback
CS450 Operating System, Spring 2015
Dr. Sang-Eon Park
21
CS450 Operating System, Spring 2015
Dr. Sang-Eon Park
22
4