Chapter 6 2 Outline Principles of Deadlock Introduction and conditions for deadlock Deadlock prevention Deadlock Avoidance Deadlock detection An Integrated deadlock strategy Concurrency Mechanisms in UNIX Linux Solaris and Windows ID: 434293
Download Presentation The PPT/PDF document "1 Concurrency: Deadlock and Starvation" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
1
Concurrency: Deadlock and Starvation
Chapter 6Slide2
2
Outline
Principles of Deadlock
Introduction and conditions for deadlock
Deadlock prevention
Deadlock Avoidance
Deadlock detection
An Integrated deadlock strategy
Concurrency Mechanisms in UNIX, Linux, Solaris and WindowsSlide3
3
Deadlock
Permanent blocking
of a set of processes that either compete for system
resources
or
communicate
with each other
Involves
conflicting
needs for resources by
two or more processes
There is no satisfactory solution in the general case
Some OS (ex: Unix SVR4) ignore the problem and pretend that deadlocks never occur...Slide4
4
Potential Deadlock
I need quad A and B
I need quad B and C
I need quad C and B
I need quad D and ASlide5
5
Actual Deadlock
HALT
until B is free
HALT
until C is free
HALT
until D is free
HALT
until A is freeSlide6
6
Two Processes P and Q
Let’s look at this with two processes P and Q.
Each needing exclusive access to a resource A and B for a period of time.
Deadlock could happen.
Whether or not deadlock occurs depends on both the dynamics of the execution and on the details of the application.Slide7
7
Example where deadlock can occurSlide8
8
Alternative logic
Suppose that P does not need both resources at the same time so that the two processes have this formSlide9
9
Example where deadlock cannot occurSlide10
10
The Conditions for Deadlock
These 3 conditions of policy must be present for a deadlock to be possible:
1
:
Mutual exclusion
only one process may use a resource at a time
2:
Hold-and-wait
a process may hold allocated resources while awaiting assignment of others
3:
No preemption
no resource can be forcibly removed from a process holding itSlide11
11
The Conditions for Deadlock
We also need the occurrence of a particular sequence of events that result in:
4:
Circular wait
a closed chain of processes exists, such that each process holds at least one resource needed by the next process in the chainSlide12
12
The Conditions for Deadlock
Deadlock occurs if and only if the circular wait condition is unresolvable
The circular wait condition is unresolvable when the first 3 policy conditions hold
Thus the 4 conditions taken together constitute necessary and sufficient conditions for deadlockSlide13
13
Resource Categories
Two general categories of resources:
Reusable
can be safely used by only one process at a time and
is not depleted
by that use.
Example?
Consumable
one that can be created (
produced
) and destroyed (
consumed
).Example?Slide14
14
Reusable Resources
Such as:
Processors, I/O channels, main and secondary memory, devices, and data structures such as files, databases, and semaphores
Deadlock
may
occur if each process holds one resource and requests the otherSlide15
15
Example of Reuse Deadlock
Consider two processes that compete for exclusive access to a disk file D and a tape drive T.
Deadlock occurs if each process holds one resource and requests the other.Slide16
16
Reusable Resources Example 1: Device RequestSlide17
17
Reusable Resources Example 2: Memory Request
Space is available for allocation of 200Kbytes, and the following sequence of events occur
Deadlock occurs if both processes progress to their second request (assuming no-preemption)
P1
. . .
. . .
Request 80 Kbytes;
Request 60 Kbytes;
P2
. . .
. . .
Request 70 Kbytes;
Request 80 Kbytes;Slide18
18
Consumable Resources
Such as Interrupts, signals, messages, and information in I/O buffers
Deadlock may occur if a Receive message is blocking
May take a rare combination of events to cause deadlockSlide19
19
Example of Deadlock
Consider a pair of processes, in which each process attempts to receive a message from the other process and then send a message to the other processSlide20
20
Resource Allocation Graphs
Directed graph that depicts a state of the system of resources and processesSlide21
21
Methods for handling deadlocks
Deadlock prevention
disallow 1 of the 4 necessary conditions of deadlock occurrence
Deadlock avoidance
do not grant a resource request if this allocation
might
lead to deadlock
Deadlock detection
always grant resource request when possible. But periodically check for the presence of deadlock and then recover from itSlide22
22
Deadlock Prevention
The OS is design in such a way as to exclude a priori the possibility of deadlock
Two main methods:
Indirect - disallow 1of the 3 policy conditions or prevent all three of the necessary conditions occurring at once
Direct - prevent the occurrence of circular waitSlide23
23
Indirect methods of deadlock prevention
Mutual Exclusion
cannot be disallowed
ex: only 1 process at a time can write to a file
Hold-and-Wait
can be disallowed by requiring that a process request all its required resources at one time
block the process until all requests can be granted simultaneously
Issues of Hold-&-Wait:
process may be held up for a long time waiting for all its requests
resources allocated to a process may remain unused for a long time. These resources could be used by other processes
an application would need to be aware of all the resources that will be neededSlide24
24
Indirect methods of deadlock prevention
No preemption
Process must release resource and request again.
But whenever a process must release a resource who’s usage is in progress, the state of this resource must be saved for later resumption.
Hence: practical only when the state of a resource can be easily saved and restored later, such as the processor.Slide25
25
Direct methods of deadlock prevention
A protocol to prevent circular wait:
define a strictly increasing linear ordering O() for resource types. Ex:
R1: tape drives: O(R1) = 2
R2: disk drives: O(R2) = 4
R3: printers: O(R3) = 7
A process initially request a number of instances of a resource type, say Ri. A single request must be issued to obtain several instances.
After that, the process can request instances for resource type Rj if and only if O(Rj) > O(Ri)Slide26
26
Prevention of circular wait
Circular wait cannot hold under this protocol. Proof:
Processes {P0, P1..Pn} are involved in circular wait iff Pi is waiting for Ri which is held by Pi+1 and Pn is waiting for Rn held which is held by P0 (circular waiting)Slide27
27
Prevention of circular wait
under this protocol, this means:
O(R0) < O(R1) < .. < O(
Rn
) < O(R0) impossible!
This protocol prevents deadlock but will often deny resources unnecessarily (inefficient) because of the ordering imposed on the requestsSlide28
28
Deadlock Prevention: Summary
We disallow 1of the 3 policy conditions or use a protocol that prevents circular wait
This leads to
inefficient
use of resources and inefficient execution of processesSlide29
29
Deadlock Avoidance
We allow the 3 policy conditions but dynamically make a decision
whether the current resource allocation request will, if granted,
potentially lead to a deadlock
. If so, t
wo approaches:
Process initial denial: do not start a process if it’s demand might lead to deadlock
Resource allocation denial:
do not grant an incremental resource request if this allocation might lead to deadlock
Assumptions:
Maximum requirements
of each resource must be stated in advance
Requires
knowledge of future process requests
Allows more concurrency than preventionSlide30
30
Resource types
Resources in a system are partitioned in
resources types
Each resource type in a system exists with a certain amount. Let R(
i
) be the total amount of resource type
i
present in the system. Ex:
R(main memory) = 128 MB
R(disk drives) = 8
R(printers) = 5
The partition is system specific (ex: printers may be further partitioned...)Slide31
31
Process initiation denial
A process is only started if the maximum claim of all current processes plus those of the new process can be met.
Let C(
k,i
) be the amount of resource type
i
claimed
by process k.
To be admitted in the system, process k must show C(
k,i
) for all resource types
i
C(
k,i
) is the maximum value of resource type
i permitted for process k.Let U(
i) be the total amount of resource type i unclaimed
(available) in the system:U(i) = R(i
) -
S
_
k
C(
k,i
)Slide32
32
Process initiation denial
A new process n is admitted in the system only if C(
n,i
) <= U(
i
) for all resource type I
This policy ensures that deadlock is always avoided since a process is admitted only if all its requests can always be satisfied (no matter what will be their order)
A
sub optimal strategy
since it assumes the worst: that all processes will make their
maximum claims together at the same time Slide33
33
Resource allocation denial: the banker’s algorithm
Processes are like customers wanting to borrow money (resources) from a bank ...
A banker should not allocate cash when it cannot satisfy the needs of all its customers
Consider a system with a fixed number of resources
State
of the system is the current allocation of resources to process:
The values of R(
i
), C(
j,i
) for all resource type
i
and process j and the values of other vectors and matrices.
Safe state
is where there is
at least one sequence
that does not result in deadlock
Unsafe state is a state that is not safeSlide34
34
Determination of Safe State
A system consisting of four processes and three resources.
Allocations are made to processors
Is this a safe state?
Can any of the four processes be run to completion with the resources available?
Amount of Existing
Resources
Resources available after allocationSlide35
35
After P2
runs to completion
Can any of the remaining processes be completed?
Note P2 is completedSlide36
36
After P1 completesSlide37
37
P3 Completes
Finally, we can complete P4. At this point,
all
of the processes have been run to completion.
Thus, the state defined originally is a safe state.Slide38
38
Determination of an Unsafe State
This time Suppose that P1 makes the request for one additional unit each of R1 and R3.
Is this safe?Slide39
39
Deadlock Avoidance
When a process makes a request for a set of resources,
assume that the request is granted,
Update the system state accordingly,
Then determine if the result is a safe state.
If so, grant the request and,
if not, block the process until it is safe to grant the request.Slide40
40
The banker’s algorithm
We also need the amount
allocated
A(j,i) of resource type i to process j for all (j,i)
The total amount
available
of resource i is given by: V(i) = R(i) -
S
_k
A(k,i)
We also use the
need
N(j,i) of resource type i required by process j to complete its task: N(j,i) = C(j,i) - A(j,i)
To decide if a resource request made by a process should be granted, the banker’s algorithm test if granting the request will lead to a
safe state
:
If the resulting state is safe then grant request Else do not grant the requestSlide41
41
The banker’s algorithm
A state is safe iff there exists a sequence {P1..Pn} where each Pi is allocated all of its needed resources to be run to completion
i.e.: we can always run all the processes to completion from a safe state
The
safety algorithm
is the part that determines if a state is safe
Initialization:
all processes are said to be “unfinished”
set the work vector to the amount resources available: W(i) = V(i) for all i; Slide42
42
The banker’s algorithm
REPEAT: Find a unfinished process j such that N(j,i) <= W(i) for all i.
If no such j exists, goto EXIT
Else: “finish” this process and recover its resources: W(i) = W(i) + A(j,i) for all i. Then goto REPEAT
EXIT: If all processes have “finished” then this state is safe. Else it is unsafe.Slide43
43
The banker’s algorithm
Let Q(j,i) be the amount of resource type i requested by process j.
To determine if this request should be granted we use the
banker’s algorithm
:
If Q(j,i) <= N(j,i) for all i then continue. Else raise error condition (claim exceeded).
If Q(j,i) <= V(i) for all i then continue. Else wait (resource not yet available)
Pretend that the request is granted and determine the new resource-allocation state: Slide44
44
The banker’s algorithm
V(i) = V(i) - Q(j,i) for all i
A(j,i) = A(j,i) + Q(j,i) for all i
N(j,i) = N(j,i) - Q(j,i) for all i
If the resulting state is safe then allocate resource to process j. Else process j must wait for request Q(j,i) and restore old state. Slide45
45
Banker’s algorithm: comments
A safe state cannot be deadlocked. But an unsafe state is not necessarily deadlocked.
Ex: P1 from the previous (unsafe) state could release temporarily a unit of R1 and R3 (returning to a safe state)
some processes may need to wait unnecessarily
sub optimal use of resourcesSlide46
46
Deadlock Avoidance Restrictions
Maximum
resource requirement must be stated in advance
Processes under consideration must be
independent
and with no synchronization requirements
Example of using shared memory (SM) among multiple processes: SM is counted multiple times
There must be a
fixed
number of resources to allocate
No process may exit
while holding resourcesSlide47
47
Deadlock Detection
Resource access are
granted
to processes
whenever possible
. The OS needs:
an algorithm to check if deadlock is present
an algorithm to recover from deadlock
The deadlock check can be performed at every resource request
Such frequent checks consume CPU timeSlide48
48
A deadlock detection algorithm
Makes use of previous resource-allocation matrices and vectors
Marks each process not deadlocked. Initially all processes are unmarked. Then perform:
Mark each process j for which: A(j,i) = 0 for all resource type i. (since these are not deadlocked)
Initialize work vector: W(i) = V(i) for all i
REPEAT: Find a unmarked process j such that Q(j,i) <= W(i) for all i. Stop if such j does not exists.
If such j exists: mark process j and set W(i) = W(i) + A(j,i) for all i. Goto REPEAT
At the end: each unmarked process is deadlockedSlide49
49
Deadlock detection: comments
Process j is not deadlocked when Q(
j,i
) <= W(
i
) for all
i
.
Then we are
optimistic
and
assume
that process j will require no more resources to complete its task.
It will thus soon return all of its allocated resources. Thus: W(
i
) = W(i
) + A(j,i) for all i.
If this assumption is incorrect, a deadlock may occur later.This deadlock will be detected the next time the deadlock detection algorithm is invoked.Slide50
50
Deadlock detection: example
What is R?
Mark P4 since it has no allocated resources
Set W = (0,0,0,0,1)
P3’s request <= W. So mark P3 and set W = W + (0,0,0,1,0) = (0,0,0,1,1)
Algorithm terminates. P1 and P2 are deadlocked. Why?
R1 R2 R3 R4 R5
P1
P2
P3
P4
Request Allocated Available
R1 R2 R3 R4 R5
R1 R2 R3 R4 R5
0 1 0 0 1
0 0 1 0 1
0 0 0 0 1
1 0 1 0 1
1 0 1 1 0
1 1 0 0 0
0 0 0 1 0
0 0 0 0 0
0 0 0 0 1Slide51
51
Deadlock Recovery
Needed when deadlock is detected. The following approaches are possible:
Abort all deadlocked processes (one of the most common solutions adopted in OS!!)
Rollback each deadlocked process to some previously defined checkpoint and restart them (original deadlock may reoccur)
Successively abort deadlocked processes until deadlock no longer exists (each time we need to invoke the deadlock detection algorithm)Slide52
52
Deadlock Recovery (cont.)
Successively preempt some resources from processes and give them to other processes until deadlock no longer exists
a process that has a resource preempted must be rolled back prior to its acquisition
For the 2 last approaches: a victim process needs to be selected according to:
least amount of CPU time consumed so far
least total resources allocated so far
least amount of “work” produced so far
Lowest priority
…Slide53
53
An integrated deadlock strategy
We can combine the previous approaches into the following way:
Group resources into a number of different classes and order them. Ex:
Swappable space (secondary memory)
Process resources (I/O devices, files...)
Main memory...
Use prevention of circular wait to prevent deadlock between resource classes
Use the most appropriate approach for each class for deadlocks within each class Slide54
54
Summary - Deadlock
Detection,
Prevention, and AvoidanceSlide55
55
Roadmap
Principals of Deadlock
Deadlock prevention
Deadlock Avoidance
Deadlock detection
An Integrated deadlock strategy
Concurrency Mechanisms in UNIX and LinuxSlide56
56
UNIX / Linux Concurrency Mechanisms
UNIX/ Linux provides a variety of mechanisms for
interprocess
communications and synchronization including:
Pipes (FIFOs)
Messages
Shared memory
Semaphores
SignalsSlide57
57
Pipes
A circular buffer allowing two processes to communicate on the producer-consumer model
first-in-first-out queue, written by one process and read by another.
Two types:
Named:
UnnamedSlide58
58
Messages
A block of bytes with an accompanying type.
UNIX provides
msgsnd
and
msgrcv
system calls for processes to engage in message passing.
Associated with each process is a message queue, which functions like a mailbox.Slide59
59
Shared Memory
A common block of virtual memory shared by multiple processes.
Permission is read-only or read-write for a process,
determined on a per-process basis.
Mutual exclusion constraints are not part of the shared-memory facility but must be provided by the processes using the shared memory.Slide60
60
Semaphores
SVR4 uses a generalization of the
semWait
and
semSignal
primitives defined in Chapter 5;
Associated with the semaphore are queues of processes blocked on that semaphore.Slide61
61
Signals
A software mechanism that informs a process of the occurrence of asynchronous events.
Similar to a hardware interrupt, without priorities
A signal is delivered by updating a field in the process table for the process to which the signal is being sent.Slide62
62
Linux Kernel Concurrency Mechanism
Includes all the mechanisms found in UNIX plus
Atomic operations
Spinlocks
Semaphores (slightly different from SVR4)
BarriersSlide63
63
Atomic Operations
Atomic operations execute without interruption and without interference
Two types:
Integer operations – operating on an integer variable
Bitmap operations – operating on one bit in a bitmap Slide64
64
Linux Atomic OperationsSlide65
65
Linux Atomic OperationsSlide66
66
Spinlock
Only one thread at a time can acquire a spinlock.
Any other thread will keep trying (spinning) until it can acquire the lock.
A spinlock is an integer
If 0, the thread sets the value to 1 and enters its critical section.
If the value is nonzero, the thread continually checks the value until it is zero.
Disadvantage?
Why
using spinlocks?Slide67
67
Semaphores
User level:
Linux provides a semaphore interface corresponding to that in UNIX
SVR4
Internally:
implemented as functions within the kernel and are more efficient than
user-
visable
semaphores
Three types of kernel semaphores:
binary semaphores
counting semaphores
reader-writer semaphoresSlide68
68
Linux
Semaphores