Scribd
Upload
33 views22 pages

Chapter 4 Process Management Deadlock

Uploaded by

Armoniem Bezabih
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
33 views22 pages

Chapter 4 Process Management Deadlock

Uploaded by

Armoniem Bezabih
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 22

CHAPTER 4-2

DEADLOCKS
System Model
• There are non-shared computer resources
• Maybe more than one instance
• Printers, Semaphores, Tape drives, CPU
• Processes need access to these resources
• Acquire resource
• If resource is available, access is granted
• If not available, the process is blocked
• Use resource
• Release resource
• Undesirable scenario:
• Process A acquires resource 1, and is waiting for resource 2
• Process B acquires resource 2, and is waiting for resource 1
 Deadlock!
Deadlocks
Definition:
Deadlock exists among a set of
processes if
• Every process is waiting for an event
• This event can be caused only by another
process in the set
• Event is the acquire of release of another resource
Four Conditions for Deadlock
• Necessary conditions for deadlock to exist:
• Mutual Exclusion
• At least one resource must be held is in non-sharable mode
• Hold and wait
• There exists a process holding a resource, and waiting for another
• No preemption
• Resources cannot be preempted
• Circular wait
• There exists a set of processes {P 1, P2, … PN}, such that
• P1 is waiting for P2, P2 for P3, …. and PN for P1

All four conditions must hold for deadlock to occur


Real World Deadlocks?
• Truck A has to wait
for truck B to
move

• Not
deadlocked
Real World Deadlocks?
• Gridlock
Dealing with Deadlocks
1. Reactive Approaches:
• Periodically check for evidence of deadlock
• For example, using a graph reduction algorithm
• Then need a way to recover
• Could blue screen and reboot the computer
• Could pick a “victim” and terminate that thread
• But this is only possible in certain kinds of applications
• Basically, thread needs a way to clean up if it gets terminated and has
to exit in a hurry!
• Often thread would then “retry” from scratch
(despite drawbacks, database systems do this)
Dealing with Deadlocks
2. Proactive Approaches:
• Deadlock Prevention
• Prevent one of the 4 necessary conditions from arising
• …. This will prevent deadlock from occurring
• Deadlock Avoidance
• Carefully allocate resources based on future knowledge
• Deadlocks are prevented
3. Ignore the problem
• Pretend deadlocks will never occur
• Ostrich approach… but surprisingly common!
Deadlock Prevention
Deadlock Prevention
• Can the OS prevent deadlocks?
• Prevention: Negate one of necessary conditions
• Mutual exclusion:
• Make resources sharable
• Not always possible (printers?)
• Hold and wait
• Do not hold resources when waiting for another
 Request all resources before beginning execution
Processes do not know what all they will need
Starvation (if waiting on many popular resources)
Low utilization (Need resource only for a bit)
• Alternative: Release all resources before requesting anything new
• Still has the last two problems
Deadlock Prevention
• Prevention: Negate one of necessary conditions
• No preemption:
• Make resources preemptable (2 approaches)
• Preempt requesting processes’ resources if all not available
• Preempt resources of waiting processes to satisfy request
• Good when easy to save and restore state of resource
• CPU registers, memory virtualization
• Circular wait: (2 approaches)
• Single lock for entire system? (Problems)
• Impose partial ordering on resources, request them in order
Deadlock Avoidance
Deadlock Avoidance
• If we have future information
• Max resource requirement of each process before they execute

• Can we guarantee that deadlocks will never occur?

• Avoidance Approach:
• Before granting resource, check if state is safe
• If the state is safe  no deadlock!
Safe State
• A state is said to be safe, if it has a process sequence
{P1, P2,…, Pn}, such that for each Pi,
the resources that Pi can still request can be satisfied by the currently
available resources plus the resources held by all P j, where j < i

• State is safe because OS can definitely avoid deadlock


• by blocking any new requests until safe order is executed

• This avoids circular wait condition


• Process waits until safe state is guaranteed
Safe State Example
• Suppose there are 12 tape drives
max need current usage could ask for
p0 10 5 5
p1 4 2 2
p2 9 2 7
3 drives remain

• current state is safe because a safe sequence exists: <p1,p0,p2>


p1 can complete with current resources
p0 can complete with current+p1
p2 can complete with current +p1+p0

• if p2 requests 1 drive, then it must wait to avoid unsafe state.


Banker’s Algorithm
• Suppose we know the “worst case” resource needs of
processes in advance
• A bit like knowing the credit limit on your credit cards. (This is why
they call it the Banker’s Algorithm)
• Observation: Suppose we just give some process ALL the
resources it could need…
• Then it will execute to completion.
• After which it will give back the resources.
• Like a bank: If Visa just hands you all the money your
credit lines permit, at the end of the month, you’ll pay your
entire bill, right?
Banker’s Algorithm
• So…
• A process pre-declares its worst-case needs
• Then it asks for what it “really” needs, a little at a time
• The algorithm decides when to grant requests
• It delays a request unless:
• It can find a sequence of processes…
• …. such that it could grant their outstanding need…
• … so they would terminate…
• … letting it collect their resources…
• … and in this way it can execute everything to completion!
The story so far..
• We saw that you can prevent deadlocks.
• By negating one of the four necessary conditions.
(which are..?)
• We saw that the OS can schedule processes in a
careful way so as to avoid deadlocks.
• Banker’s algorithm.
• What are the downsides to these?
Deadlock Detection & Recovery
• If neither avoidance or prevention is implemented,
deadlocks can (and will) occur.
• Coping with this requires:
• Detection: finding out if deadlock has occurred
• Keep track of resource allocation (who has what)
• Keep track of pending requests (who is waiting for what)
• Recovery: untangle the mess.
• Expensive to detect, as well as recover
Using the Resource Allocation Graph to detect
deadlocks
• Suppose there is only one instance of each resource
• Example 1: Is this a deadlock?
• P1 has R2 and R3, and is requesting R1
• P2 has R4 and is requesting R3
• P3 has R1 and is requesting R4
• Example 2: Is this a deadlock?
• P1 has R2, and is requesting R1 and R3
• P2 has R4 and is requesting R3
• P3 has R1 and is requesting R4
When to run Detection Algorithm?
• For every resource request?
• For every request that cannot be immediately satisfied?
• Once every hour?
• When CPU utilization drops below 40%?
Deadlock Recovery
• Killing one/all deadlocked processes
• Crude, but effective
• Keep killing processes, until deadlock broken
• Repeat the entire computation
• Preempt resource/processes until deadlock broken
• Selecting a victim (# resources held, how long executed)
• Rollback (partial or total)
• Starvation (prevent a process from being executed)

You might also like