1. ITEC 202 Operating Systems
EASTERN MEDITERRANEAN UNIVERSITY
SCHOOL OF COMPUTING AND TECHNOLOGY
DEADLOCK
ITEC 202 Operating Systems

2. Deadlock
In a multiprogramming environment, several processes may compete for a finite number of resources.
A process requests resources; if the resources are not available at that time, the process enters to waiting state.

3. Deadlock
It may happen that waiting processes will never again change state, because the resources they have requested are held by other waiting processes.
This situation is called deadlock.

4. Categories of resources
Reusable resources
Consumable resources

5. Reusable resources
A reusable resource is one that can be used by only one process at a time
These resources are released after used for reuse by other processes
Processor
Memory
I/O Devices

6. Example of Deadlock (request for main memory)
Space is available for allocation of 200K bytes, and the following sequence of events occur P1 …
Request 80 Kbytes;
Request 60 Kbytes; P2
Request 70 Kbytes;
After the first request of P1 and P2 only 50K bytes are available.
Deadlock occurs if both processes progress to their second request

7. Example of Deadlock Deadlock Occurs 200 K 120 K 50 K
Available Memory :
200 K
120 K
50 K
Process Process 2
Request 70 Kbytes
Request 80 Kbytes 
Request 80 Kbytes
Request 70 Kbytes 
Request 60 Kbytes
Request 80 Kbytes
Deadlock Occurs

8. Is it possible to avoid Deadlock?
Available Memory :
200 K
200 K
60 K
Process Process 2
Request 80 Kbytes 
Request 80 Kbytes
Request 70 Kbytes
Request 80 Kbytes
Request 60 Kbytes 
Request 60 Kbytes

9. Consumable resources
A consumable resource is one that can be created and destroyed.
Typically, there is no limit on the number of consumable resources.
Once a consumable resource is used (acquired) by the process, it is no longer available for others.
Interrupts
Messages
signals

10. Resource allocation graphs
Within a resource node, a dot is shown for each instance of that resource
A graph edge directed form a process to a resource indicates a resource that has been requested by the process but not yet granted
A graph edge directed form a reusable resource node dot to a process indicates a request that has been granted; that is, the process has been assigned one unit of that resource.

11. Circular Wait An example deadlock.
There is only one unit each of resources Ra and Rb. Process P1 holds Rb and requests Ra, while P2 holds Ra but requests Rb.

12. Multiple unit of each resources
No deadlock
Has the same topology as circular wait, but there is no deadlock because multiple units of each resource are available

13. Multiple unit of each resources
No deadlock

14. Another deadlock situation
In this case, we do not have a simple situation which two processes each have one resource the other needs.
Rather, in this case, there is a circular chain of processes and resources that result in deadlock.

15. Resource-Allocation Graph, cont.
If graph contains no Cycles no deadlock
If graph contains a cycle
if only one instance per resource type, then deadlock
if several instances per resource type, possibility of deadlock

16. Is there any deadlock in the following situation?

17. Both P2 and P4 have all of their requests so they can run to completion.

18. When P2 and P4 end, one unit of R1 and R2 are free and can be assigned to P1 and P3.

19. Hence there is no deadlock in this situation.
Since both P1 and P3 have all of their requests, they can now run to completion too.
Hence there is no deadlock in this situation.

20. Example:
P is a set of processes. R is a set of resources. E is a set of request or assignment edges. The sets P,
R, and E are as follows:
P = {P1, P2, P3}, R = {R1,R2,R3}
E = {P1R1, P2R3, P3R2, R1P2, R2P2,
R2P1, R3P3}
R1 has one instance. R2 has two instances. R3 has one instance.
(a) Draw the resource-allocation graph.
(b) Is there any deadlock in this situation? Briefly Explain.

21. (a) Draw the resource-allocation graph.
P = {P1, P2, P3}, R = {R1,R2,R3}
E = {P1R1, P2R3, P3R2, R1P2, R2P2, R2P1, R3P3}

22. (a) Draw the resource-allocation graph.
P = {P1, P2, P3}, R = {R1,R2,R3}
E = {P1R1, P2R3, P3R2, R1P2, R2P2, R2P1, R3P3}

23. (a) Draw the resource-allocation graph.
P = {P1, P2, P3}, R = {R1,R2,R3}
E = {P1R1, P2R3, P3R2, R1P2, R2P2, R2P1, R3P3}

24. (b) Is there any deadlock in this situation?
Consider the resource-allocation graph. One cycle exist in the system.
P1  R1  P2  R3  P3  R2  P1
P1, P2, and P3 are deadlocked

25. Conditions for deadlock
Mutual exclusion
Hold and wait
No preemption
Circular wait
All four conditions listed above MUST hold for a deadlock to occur

26. Conditions for deadlock
Mutual exclusion
Only one process may use a resource at a time.
No process may access a resource unit that has been allocated to another process.
Resources cannot be shared

27. Conditions for deadlock
Hold and wait
A process may hold allocated resources while awaiting assignment of other resources.
A process is both holding a resource and waiting for another resource to become free

28. Conditions for deadlock
No preemption
No resource can be forcibly removed from a process holding it.
Once a process (thread) gets a resource, it cannot be taken away

29. Conditions for deadlock
Circular wait
A closed chain of processes exists, such that each process holds at least one resource needed by the next process in the chain
There is a cycle in the graph of who has what and who wants what…

30. Methods for Handling Deadlocks
Deadlock prevention
Deadlock avoidance
Deadlock detection and recovery
Ignore

31. Methods for Handling Deadlocks
Deadlock prevention
deadlock can be prevented by removing one deadlock condition
design a system in such a way that the possibility of deadlock is excluded

32. Methods for Handling Deadlocks
Deadlock avoidance
allows the three necessary conditions, but assures that deadlock point is never reached
reject resource requests that might lead to deadlock

33. Methods for Handling Deadlocks
Deadlock detection and recovery
detect the deadlock
figure out when deadlock has occurred and “deal with it”

34. Methods for Handling Deadlocks
Ignore problem and reboot when necessary…
used far too often in practice

35. Prevention occurrence of a deadlock
The strategy of deadlock prevention is to design a system in such a way that the possibility of deadlock is excluded.
At least one of the necessary four deadlock conditions should be prevented.

36. Prevention occurrence of a deadlock
Mutual Exclusion:
There is no possibility to disallow this condition, as resources needs sharing and mutual exclusion has to be supported by the operating system.

37. Prevention occurrence of a deadlock
Hold and Wait:
To prevent this condition, a process should allocate all resources that it needs before starting.
Several possibilities to disallow this condition…
Never require more than one resource at a time
Reject any request that might lead to deadlock
Require all resources to be acquired at once
Require current resources to be freed and reacquired if need more

38. Prevention occurrence of a deadlock
Problems with avoiding Hold and Wait condition:
block the process until all requests can be granted simultaneously
resources 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

39. Prevention occurrence of a deadlock
No preemption:
if a process is denied a further request, the process must release the original resources
if a process requests a resource that is currently held by another process, OS may preempt the second process and require it to release its resources
practical only when the state can be easily saved and restored later, such as the processor

40. Prevention occurrence of a deadlock
Circular wait
prevented using linear ordering for resources
may deny resources unnecessarily

41. Deadlock Avoidance
A decision is made dynamically whether the current resource allocation request will, if granted, potentially lead to a deadlock
Requires knowledge of future process request

42. Two Approaches to Deadlock Avoidance
Do not start a process if its demands might lead to deadlock
Do not grant an incremental resource request to a process if this allocation might lead to deadlock

43. Process initiation denial
R Resource vector, total amount of each resource in the system
V Available resources vector, total amount of resources not allocated to any process
C Resource claim matrix, represents requirements of the processes for each resources
A Resource allocation matrix, represents current allocations of processes to resources

44. Process initiation denialQ
Request matrix
Needs matrix
Request matrix = Claim matrix – Allocation matrix
Q=C-A

45. Resource allocation denial (banker’s algorithm)
Referred to as the banker’s algorithm
State of the system is the current allocation of resources to process
Safe state is one in which there is at least one order in which all the processes can run to completion without resulting in deadlock
Unsafe state is a state that is not safe

46. Determination of safe state
The question: is this safe state? That is, do we have a state which there is at least one order in which all the processes can be run to completion without resulting in a deadlock? 1 6 2 3 4
Initial
State

47. Determination of a Safe State P2 Runs to Completion
by assigning one unit of R3 to process P2, P2 has its maximum required resources allocated and can run to completion. 1 6 3 2 4

48. Determination of a Safe State P2 Runs to Completion
When P2 competes, its resources can be returned to the pool of available resources. 1 2 3 4 6

49. Determination of a Safe State P1 Runs to Completion2 1 3 4 7

50. Determination of a Safe State P3 Runs to Completion2 4 9 3

51. Determination of a Safe State P4 Runs to Completion9 3 6
Processes can complete in the order P2, P1, P3, P4

52. EX:
Suppose that P2 makes a request for one additional unit of R1 and one additional unit of R3. 1 5 2 3 4

53. Safe Processes can complete in the order P2, P1, P3, P46 2 3 4
If we assume that the request is granted, then the resulting state is the initial state given in the previous example. We have already seen that this is a safe state; therefore it is safe to grant the request.

54. Determination of unsafe state
Suppose that P1 makes the request for one additional unit each of R1 and R3
Initial
state 1 5 2 3 4

55. Determination of unsafe state
assume that the request is granted
Is this a safe state? NO
unsafe
state 2 1 5 3 4

56. Deadlock detection Deadlock prevention strategies
limits access to resources
imposes restrictions on process
Deadlock detection strategies
do not limit resource access or restrict process actions
requested resources are granted to processes whenever possible

57. Deadlock recovery
Once a deadlock has been detected, some strategy is needed for recovery.
The followings are possible approaches:
Abort all deadlocked processes. This is not the most common strategy but quite effective.
Back up each deadlocked process to some previously defined checkpoint, and restart all processes. The potential risk in this approach is that original deadlock may occur again.

58. Deadlock recovery
Successively abort the deadlocked processes until deadlocked is resolved
based on minimum cost criterion.
Successively preempt (block) resources until deadlock is resolved
should be based on minimization of some cost function.

59. Following techniques can be used for cost minimizing criteria That is choose the process with the:
Least amount of time consumed by the process so far.
Least amount of output produced so far.
Most estimated time remaining (not easy to determine).
Least total resources allocated so far.
Lowest priority.

60. Exercise Is this a safe state or not?P1 3 2 1 P2 P3 4
Claim matrix C
Allocation matrix A R1 R2 R3 2 1
Available vector V

61. Is this a safe state or not?P1 1 2 P2 P3 3
C-A
(Request matrix, Q) R1 R2 R3 P1 3 2 1 P2 P3 4
Claim matrix C
Allocation matrix A R1 R2 R3 2 1
Available vector V
Unsafe State

62. Exercise A system that use Banker’s algorithm for deadlock avoidance has five processes and four types of resources. There are multiple resources of each type. Is the following state safe or not? If it is, show how the processes can complete. If not, show how they deadlock.

63. Solution: The first step is the calculation of Needs (Request) matrix, that is Q=C-A.

64.
Only P5 can run with these available resources, so P5 runs to completion then:

65. Then P3 runs to completion then:
Then P3 runs to completion then:

66. Then P4 runs to completion then:
Then P4 runs to completion then:

67. Then P1 runs to completion then:
Then P1 runs to completion then:

68. Then P2 runs to completion then:
Then P2 runs to completion then:

69. Solution: So, the given state is a safe state
Solution: So, the given state is a safe state. The safe order which the processes can run is P5, P3, P4, P1 and P2

70. Summary
In summary, a deadlock is when a process has some resource and is waiting to acquire another resource, while that resource is being held by some process that is waiting to acquire the resource that is being held by the original process.
We can handle deadlocks in three major ways: We can prevent them, Handle them when we detect them, or simply ignore the whole deadlock issue altogether.

71. Summary A deadlock needs four conditions to occur Mutual Exclusion
2 processes cannot use a resource at the same time
Hold and Wait
process holds a resource and requests another
No-Preemption of resources
the system doesn't take away resources from waiting processes - processes release resources voluntarily after they are finished using them
Circular Waiting
there must exist a waiting chain such that processes are waiting for other processes that are waiting for the original processes to release some resource

72. Summary Four techniques for handling deadlock
Prevention: Design rules so one condition cannot occur
Avoidance: Dynamically deny “unsafe” requests
Detection and recovery: Let it happen, notice it, and fix it
Ignore: Do nothing, hope it does not happen, reboot often

73. sct.emu.edu.tr/itec202 Ahmet Rizaner Operating Systems Lecture Notes
5 April 2009