Kai Bu kaibu@zju.edu.cn http://list.zju.edu.cn/kaibu/cmpt300 06 Deadlock In previous lectures, we discussed a series of solutions to synchronize cooperating.

Kai Bu kaibu@zju.edu.cn http://list.zju.edu.cn/kaibu/cmpt300
06 Deadlock In previous lectures, we discussed a series of solutions to synchronize cooperating processes over shared resources. We noticed that a careless design may lead to a deadlock Kai Bu

Deadlock in the course of synchronization
sometimes during the synchronization. *side notes: During vs In the course of:

Deadlock in the course synchronization
if two or more processes are waiting indefinitely for an event that can be caused only by one of the waiting procs As you may still remember, a deadlock occurs when two or more processes are waiting for a shared resource, But that shared resource is currently held/occupied by other waiting processes, And those waiting processes may be, in turn, waiting for some resources held by the waiting processes that wait for their held resources.

Deadlock in the course synchronization example: P0 P1 wait(S) wait(Q)
wait(Q) wait(S) cs… cs… A simple example to demonstrate a deadlock would be: Two processes, P0 and P1, they both need two shared resources ---semaphores S and Q --- before accessing the critical section. Consider a scheduling sequence when the computer system runs P0’s wait(s) first and then P1’s wait(Q). After these two operations, P0 needs to acquire Q, which is currently held by P1. While P1 needs to acquire S to proceed, but S is currently held by P0. So, it’s down to this situation that both P0 and P1 wait for each other to proceed, but one process can only proceed after the other completes and releases the acquired resource. 1st run 2nd run

Deadlock in the course synchronization example: dining philosophers
We also covered the dining philosopher problem

In this example, n philosophers sit at a circular table.
They are provided with n forks, but each philosopher insists that he needs two forks to eat. At this one moment, all philosophers decide to eat and start grapping his left fork. Each of them starts waiting for his right fork, which is currently held by his right neighbor and only will be released after grabbing his left fork from his left neighbor and eat.

Deadlock in the course synchronization example: even in a reality show

Such as the X factor show

Deadlock when to care? In a deadlock, processes never finish executing, And system resources are tied up, preventing other jobs from starting. Apparently, we don’t want it to happen. Then the question is, given a computer system and a specific program to run, will a deadlock be possible?

Four Necessary Conditions
Mutual exclusion Hold and wait No preemption Circular wait Here are four necessary conditions for a deadlock to occur. We can use them to examine our computer system and program and see whether a deadlock may occur.

Mutual exclusion at least one nonsharale resource, only one process at a time can use it. Hold and wait No preemption Circular wait The first condition is of course mutual exclusion. Cause if a resource can be simultaneously accessed by multiple processes, it will not make any process wait and deadlock. At least one resource must be held in a nonsharable mode; that is, only one process at a time can use the resource. If another process requests that resource, the requesting process must be delayed until the resource has been released.

Mutual exclusion Hold and wait A process must be holding at least one resource and waiting to acquire additional resources that are currently being held by other processes. No preemption Circular wait The second condition is hold and wait. It requires that a process must be holding at least one resource and waiting to acquire additional resources that are currently being held by other processes.

Mutual exclusion Hold and wait No preemption Resources cannot be preempted. Circular wait The third condition is no preemption. That is, resources currently held by some processes but requested by other waiting processes cannot be preempted. Otherwise, it’s easy to break the tie.

Mutual exclusion Hold and wait No preemption Circular wait A set {P0, P1, …, Pn} of waiting processes must exist such that P0 is waiting for a resource held by P1, P1 is waiting for P2, …, Pn-1 is waiting for Pn, and Pn is waiting for P0 The fourth condition is circular wait. Similar as what we have noticed in the dining philosophers problem, the condition of circular wait requires that …;

Deadlock how to spot? If the computer system and program happen to satisfy all the four conditions, How to spot the exact deadlock?

Resource-Allocation Graph
resources processes Toward that goal, we use resource allocation graph to track the resource allocation status/state. Two types of vertices: processes and resources, Each type of resource may have more than one instance;

request edge: P1 is waiting for an instance of R1 assignment edge: one R2 instance is held by P2 Two types of directed edges: Request edge: from process to resource; Assignment edge: from resource to process;

At this moment, this example is deadlock free if all processes require no more resources: Then P3 runs first, after it completes, it releases R3. Then P2 have all requested resources available, start running. When it completes, it’ll release all allocated resources including R1, R2, and R3. Since P1 is waiting for R1, and now R1 becomes available. P1 can then be allocated with R1 and executed. deadlock free if no process requests more resources to run

But if P3 further requests an instance of R2 to run, Then this example will suffer from a deadlock. Why? deadlock if P3 further requests an instance of R2

Deadlock how to prevent?

Deadlock Prevention By ensuring that at least one of the four necessary conditions cannot hold As we discussed earlier, there are four necessary conditions that should simultaneously hold for a deadlock to occur. By ensuring that at least one of the four necessary conditions cannot hold, We can prevent the occurrence of a deadlock. Next, let’s walk through each condition, see whether it can be refrained; and if yes, how to.

Mutual Exclusion “Sorry, just stick with that.”
Some resources are intrinsically nonsharable. e.g., a mutex lock For the first mutual exclusion condition, Actually, we cannot prevent it, Cause some resources in our computer system are just intrinsically nonsharable. For example, a mutex lock cannot be simultaneously shared by several processes.

Hold and Wait By ensuring that whenever a process requests a resource, it does not hold any other resources. For the second hold and wait condition, to ensure that it never occurs in the system, We need to ensure that whenever a process requests a resource, it does not hold any other resources.

Hold and Wait Solution 1:
each process requests and is allocated all its resources before it begins execution; can be implemented by requiring that system calls requesting resources for a process precede all other system calls; One solution that we can use requires each process to request and be allocated ALL its resources before its execution. We can implement this solution by requiring that system calls requests resources for a process precede all other system calls.

Hold and Wait Solution 2:
each process requests resources only when it has none; a process may request some resources and use them; before it can request any additional resources, it must release all resources that it is currently allocated; Another solution allows a process to request resources only when it has none. A process may request some resources and use them. Before it can request any additional resources, it must release all the resources that it is currently allocated.

Hold and Wait Solution 2 or Solution 1?
Now given the two possible solutions which one do you think we should choose?

Hold and Wait Solution 2 vs Solution 1: Example
copy data from DVD to file, then print file Solution 1: allocate all resources (DVD, file, printer) to the process, even though printer is not needed while copying Solution 2: DVD+file; then file+printer Let’s use an example to compare the two solutions.

No Preemption By ensuring that processes can be preempted
To refrain the third non-preemption condition, obviously we need to reintroduce preemption back to scheduling.

No Preemption Solution 1:
if a process is holding some resources and requests another unavailable resource, then all resources held by the process are released;

No Preemption Solution 2: if a process requests some resources,
check resource availability, if available, allocate them; if not and allocated to a waiting proc, preemt the waiting proc, allocate to the requesting process;

Circular Wait Impose a total ordering of all resources
Require that each process request resources in an increasing order of enumeration Example: three waiting processes P0 allocated with R0, waiting for R1 P1 allocated with R1, waiting for R2 P2 allocated with R2 where R0 < R1 < R2 Discussion

Require that each process request resources in an increasing order of enumeration Example: three waiting processes P0 allocated with R0, waiting for R1 P1 allocated with R1, waiting for R2 P2 allocated with R2 where R0 < R1 < R2 Discussion cannot request R0 as R0<R1

Require that each process request resources in an increasing order of enumeration Example: three waiting processes P0 allocated with R0, waiting for R1 P1 allocated with R1, waiting for R2 P2 allocated with R2 where R0 < R1 < R2 Discussion cannot request R0 as R0<R1 no circular wait

Deadlock how to increase device utilization and system throughput while handling dls? Possible side effects of preventing deadlocks by refraining one or more necessary conditions are low device utilization and reduced system throughput. Then, how to increase device utilization and system throughput while handling deadlocks?

Deadlock Avoidance Require additional information about how resources are to be requested For resource allocation decision, consider the resources currently available, the resources currently allocated to each process, and the future requests and releases of each process. A feasible alternative is called deadlock avoidance. It requires additional information about how resources are to be requested. Each request requires that in making this decision the system consider the resources currently available, the resources currently allocated to each process, and the future requests and releases of each process.

Safe State State the number of available and allocated resources and the maximum demands of the processes Safe state the system can allocate resources to each process (up to its maximum) in some order and still avoid a deadlock The first deadlock avoidance solution is called safe state. The state of the resource allocation is defined by the number of available and allocated resources and the maximum demands of the processes. A state is safe if the system can allocate resources to each process (up to its maximum) in some order and still avoid a deadlock.

Safe State A system is in a safe state only if there exists a safe sequence A sequence of processes <P1, P2,…,P3> is safe for the current allocation state if, for each Pi, the resource requests that Pi can still make can be satisfied by the currently available resources plus the resources held by all Pj, where j<i. More formally, a system is in a safe state only if there exists a safe sequence. A sequence of processes P1, P2, P3 is a safe sequence for the current allocation state if…;

Safe State Deadlock avoidance solution:
ensure that the system will always remain in a safe state; initially, the system is in a safe state; whenever a process requests a resource that is currently available, the request is granted only if the allocation leaves the system in a safe state;

Safe State Example: 12 resources in total Maximum Needs Current Needs
The example system is in a safe state, because of a safe sequence <P1,P0,P2 > allocated

Besides request/assignment edges, introduce a claim edge as a dashed line that indicates Pi may request Rj at some time in the future A claim edge can become a assignment edge only if it does not result in a cycle

If P2 requests R2, not granted because R2P2 leads to a cycle/deadlock But this model does not support multi-instance resource allocation.

Banker’s Algorithm Allocate resources each with multiple instances
Can be used in a banking system to ensure that the bank never allocated its available cash in such a way that it could no longer satisfy the needs of all its customers Allocate requested resources if they keep the system in a safe state Another solution called the banker’s algorithm can support allocating resources each with multiple instances.

Banker’s Algorithm Data Structures: n procs, m res types
Available[j] = k k instances of res type Rj are available Max[i][j] = k proc Pi may request at most k instances of resource type Rj Allocation[i][j]=k proc Pi is currently allocated k instances of resource type Rj Need[i][j]=Max[i][j]-Allocation[i][j]=k proc Pi needs k more resources of type Rj

Banker’s Algorithm Safety Algorithm: Is sys in safe state?
1. Work = Available 1. Finish[i] = false, for i=0, 1, …, n-1 2. Find an index i such that both 2. a. Finish[i] == false 2. b. Needi <= Work 2. If no such I exists, go to step 4 3. Work = Work + Allocationi 3. Finish[i] = true 3. Go to step 2. 4. If Finish[i]==true for all i, then sys is safe

Banker’s Algorithm Resource-Request Algorithm:
Can equests be safely granted? 1. If Requesti <= Needi, go to step 2; 1. Otherwise, error, as exceeding max 2. If Requesti <= Available, gt step 3; 2. Otherwise, Pi must wait 3. Test whether allocation induces unsafe state: 3. Available = Available – Requesti; 3. Allocationi = Allocationi + Requesti; 3. Needi = Needi – Requesti; 3. If the resulting state is safe, allocate; 3. Otherwise, Pi must wait; restore old-allocation sate

Deadlock what if no prevention/avoidance?
So far, we investigated several deadlock prevention and avoidance solutions. Obviously each of them has its own pros and cons. And they all require additional efforts for the computer system to implement and maintain. And it’s also normal that most computer systems may not employ any prevention or avoidance solution. Apparently, when no prevention or avoidance solution is used, a deadlock may occur.

Deadlock what if no prevention is employed? how to detect?
Then the question is, how to detect whether a deadlock occurs?

Single-Instance Resource
Single instance per resource type Wait-for graph contain only process vertices; edge PiPj exists if Pi is waiting for process Pj to release a resource R; that is, both PiR and RPj exist in resource-allocation graph; If all resources have only a single instance, we can use a wait-for graph to detect a deadlock. A wait-for graph is a variant of the previously discussed resource-allocation graph. It contains only vertices for processes. An edge from Pi to Pj exists if Pi is waiting for Pj to release some resource R; That is, in the corresponding resource-allocation graph, both edges Pi to R and R to Pj should exist.

Wait-for Graph (a) resource-allocation (b) wait-for
Here’s an example wait-for graph.

Wait-for Graph deadlock? if and only if a circle exists?
(a) resource-allocation (b) wait-for deadlock? if and only if a circle exists? In this example, does a deadlock exist? How to detect?

(a) resource-allocation (b) wait-for deadlock? if and only if a circle exists?

but not if more instances per resource? (a) resource-allocation (b) wait-for We also mentioned that, when a resource has sufficient instances, then a cycle in the resource allocation graph or wait-for graph does not necessarily induce a deadlock.

Multi-Instance Resource
Data structures: m res types, n procs Available m-size vector indicates res availability; Allocation: n x m matrix Allocation[i][j] = k indicates that Pi is allocated k instances of Rj Request: n x m matrix Request[i][j] = k indicates that Pi requests k more instances of Rj Then for the system with multi-instance resources, how can we detect a deadlock?

Deadlock Detection Alg
1. Work = Available; 1. Finish[i] = false, if Allocationi != 0; 1. Finish[i] = true, otherwise; 2. Find an index i such that both 2. a. Finish[i] == false 2. b. Requesti <= Work 2. If no such i, go to step 4. 3. Work = Work + Allocationi 3. Finish[i] = True 3. Go to step 2. 4. If exists Finish[i] == false, deadlock

Example 1: Deadlock? Allocation Request Available ABC P0 010 000 P1 200 202 P2 303 P3 211 100 P4 002

Example 1: Deadlock? <P0> Allocation Request Available ABC P0 010 000 P1 200 202 P2 303 P3 211 100 P4 002

Allocation Request Available ABC P0 010 000 P1 200 202 P2 303 P3 211 100 P4 002

Example 1: Deadlock? <P0, P2> Allocation Request Available ABC P0 010 000 P1 200 202 P2 303 313 P3 211 100 P4 002

Example 1: Deadlock? <P0, P2, P3 > Allocation Request Available ABC P0 010 000 P1 200 202 P2 303 313 P3 211 100 524 P4 002 Similarly, next one to run is P3,

Example 1: Deadlock? <P0, P2, P3, P1> Allocation Request Available ABC P0 010 000 P1 200 202 724 P2 303 313 P3 211 100 524 P4 002 Either P1 or P4 is runnable. Assume P1 first,

Example 1: Deadlock? No <P0, P2, P3, P1, P4> Allocation Request Available ABC P0 010 000 P1 200 202 724 P2 303 313 P3 211 100 524 P4 002 726 Then P4. All are executed with requested resources allocated; Then no deadlock;

Example 2: Deadlock? Allocation Request Available ABC P0 010 000 P1 200 202 P2 303 001 P3 211 100 P4 002 Change example 1 a bit, by letting P2 request one more instance of C

Example 2: Deadlock? Allocation Request Available ABC P0 010 000 P1 200 202 P2 303 001 P3 211 100 P4 002 Again, run P0 first since it requests no more resources; Then after it completes, releases its allocated resources, that is, one instance of B, Making the available vector 010, which is insufficient for the request vector of all the remaining processes; Which means, no other processes can obtain sufficient resources to keep running, get stuck, and lead to a deadlock

Example 2: Deadlock? Yes Allocation Request Available ABC P0 010 000 P1 200 202 P2 303 001 P3 211 100 P4 002 Again, run P0 first since it requests no more resources; Then after it completes, releases its allocated resources, that is, one instance of B, Making the available vector 010, which is insufficient for the request vector of all the remaining processes; Which means, no other processes can obtain sufficient resources to keep running, get stuck, and lead to a deadlock

Deadlock what if a deadlock is detected? how to recover?
After detecting a deadlock, how to recover from the deadlock state?

Process Termination Abort one or more processes
Reclaim all allocated res from them Which process(es) to abort? Then the question is which processes to abort?

Process Termination Abort all deadlocked processes at great expense:
waste previous computation efforts, recomputation may be needed; Abort one process at a time until the deadlock cycle is eliminated high overhead: invoke deadlock-detection algorithm after each process is aborted; Two options;

Resource Preemption Successively preempt some resources from processes
Give these resources to other procs until the deadlock cycle is broken Caveats? What need to pay attention to?

Resource Preemption Selecting a victim Rollback Starvation
determine min-cost order of preemption; e.g., no. of preempted resources, time taken by preempted processes Rollback roll back the preempted process to some safe state; restart it from that state; Starvation ensure that a process can be preempted only a (small) finite number of times

#what’s more

politeness always helps

“After you, Sir.”

Review What’s deadlock? When’s a deadlock occurring?
How to prevent, avoid, detect deadlock? How to recover from deadlock?

Chapter 7 The contents to be discussed can be found in chapters 3 and 4.

Reminder Assignment 1 Due: June 21, 2018 on CourSys Midterm Exam AQ3150, 11:30 – 13:20 June 26, 2018

Thank You

#What’s More You Are Not Special by David McCullough Jr.
Is Smiling Contagious? by Sue Heck

Kai Bu kaibu@zju.edu.cn http://list.zju.edu.cn/kaibu/cmpt300 06 Deadlock In previous lectures, we discussed a series of solutions to synchronize cooperating.

Similar presentations

Presentation on theme: "Kai Bu kaibu@zju.edu.cn http://list.zju.edu.cn/kaibu/cmpt300 06 Deadlock In previous lectures, we discussed a series of solutions to synchronize cooperating."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Kai Bu kaibu@zju.edu.cn http://list.zju.edu.cn/kaibu/cmpt300 06 Deadlock In previous lectures, we discussed a series of solutions to synchronize cooperating.

Similar presentations

Presentation on theme: "Kai Bu kaibu@zju.edu.cn http://list.zju.edu.cn/kaibu/cmpt300 06 Deadlock In previous lectures, we discussed a series of solutions to synchronize cooperating."— Presentation transcript:

Similar presentations

About project

Feedback