Download Deadlock Problem, Deadlock Characterization - Introduction to Operating System - Lecture Note and more Lecture notes Operating Systems in PDF only on Docsity!
Operating Systems--[CS-604] Lecture No. 26
Operating Systems
Lecture No. 26
Reading Material
Chapters 7 and 8 of the textbook Lecture 26 on Virtual TV
Summary
Monitor-based solution of the dining philosophers problem The deadlock problem Deadlock characterization Deadlock handling Deadlock prevention
Monitor-based Solution for the Dining Philosophers Problem
Let us illustrate these concepts by presenting a deadlock free solution to the dining philosophers problem. Recall that a philosopher is allowed to pick up her chopsticks only if both of them are available. To code this solution we need to distinguish among three states in which a philosopher may be. For this purpose we introduce the following data structure:
enum {thinking, hungry, eating} state[5];
Philosopher i can set the variable state[i]=eating only if her two neighbors are not eating: (state[(i+4)%5]!=eating) and (state[(i+1)%5]!=eating).
We also need to declare five condition variables, one for each philosopher as follows. A philosopher uses her condition variable to delay herself when she is hungry, but is unable to obtain the chopsticks she needs.
condition self[5];
We are now in a position to describe our monitor-based solution to the dining- philosophers problem. The distribution of the chopsticks is controlled by the monitor dp; whose definition is as follows:
monitor dp { enum {thinking,hungry,eating} state[5]; condition self[5];
void pickup(int i) { state[i]=hungry; test(i); if (state[i] != eating) self[i].wait(); } void putdown(int i) { state[i]=thinking; test((i+4)%5); test((i+1)%5); } void test(int i) { if ((state[(i+4)%5]!=eating) && (state[i]==hungry)&& state[(i+1)%5]!=eating)) { state[i]=eating; self[i].signal(); } } void init() { for(int i=0;i<5;i++) state[i]=thinking; } }
Each philosopher before starting to eat must invoke the pickup operation. This operation ensures that the philosopher gets to eat if none of its neighbors are eating. This may result in the suspension of the philosopher process. After the successful completion of the operation, the philosopher may eat. Following this, the philosopher invokes the putdown operation and may start to think. The putdown operation checks if a neighbor (right or left—in this order) of the leaving philosopher wants to eat. If a neighboring philosopher is hungry and neither of that philosopher’s neighbors is eating, then the leaving philosopher signals it so that she could eat. In order to use this solution, a philosopher i must invoke the operations pickup and putdown in the following sequence:
In the next three to four lectures, we will discuss the issue of deadlocks in computer systems in detail.
System Model
A system consists of a finite number of resources to be distributed among a finite number of cooperating processes. The resources are partitioned into several types, each of which consists of some number of identical instances. Memory space, CPU cycles, disk drive, file are examples of resource types. A system with two identical tape drives is said to have two instances of the resource type disk drive. If a process requests an instance of a resource type, the allocation of any instance of that type will satisfy the request. If it will not, then the instances are not identical and the resource type classes have not been defined properly. A process must request a resource before using it, and must release the resource after using it. A process may request as many resources as it requires in order to carryout its designated task. Obviously, the number of resources requested may not exceed the total number of resources available in the system. Under the normal mode of operation, a process may utilize a resource in only the following sequence:
- Request: The process requests a needed resource. If the request cannot be granted immediately, then the requesting process must wait until it can acquire the resource.
- Use: The process can use the resource.
- Release: The process releases the resource.
Deadlock Characterization
The following four conditions must hold simultaneously for a deadlock to occur:
- Mutual exclusion : At least one resource must be held in a non-sharable 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.
- 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 : Resources cannot be preempted. That is, after using it a process releases a resource only voluntarily.
- Circular wait : A set {P 0 , P 1 … Pn } of waiting processes must exist such that P 0 is waiting for a resource that is held by P 1 , P 1 is waiting for a resource that is held by P 2 , and so on, Pn-1 is waiting for a resource held by Pn, and Pn is waiting for a resource held by P0.
P i
Pi
Resource Allocation Graphs
Deadlocks can be described more precisely in terms of a directed graph called a system resource allocation graph. This graph consists of a set of vertices V and a set of edges E. The set of vertices is portioned into two different types of nodes P={P 0 , P 1 … Pn }, the set of the active processes in the system, and R={R 0 , R 1 … Rn }, the set consisting of all resource types in the system. A directed edge from a process P (^) i to resource type Rj signifies that process Pi requested an instance of Rj and is waiting for that resource. A directed edge from Rj to Pi signifies that an instance of Rj has been allocated to Pi. We will use the following symbols in a resource allocation graph.
- Process
- Resource Type with 4 instances
- Pi requests instance of Rj
- Pi is holding an instance of Rj
The resource allocation graph shown below depicts the following situation: P={P 1 , P2, P 3 } R={R 1 , R 2 , R 3 } E={P 1 → R 1 , P 2 → R 3 , R 1 → P 2 , R 2 → P 2 , R 2 → P 1 , P 3 → R 3 }
Resource Instances
One instance of resource type R 1 Two instances of resource type R 2 One instance of resource type R 3 Three instances of resource type R 4
Process States
Process P 1 is holding an instance of resource R 2 , and is waiting for an instance of resource R 1. Process P 2 is holding an instance of resource R 1 and R 2 , and is waiting for an instance of resource R 3. Process P 3 is holding an instance of resource R3.
The graph shown below has a cycle but there is no deadlock because processes P and P4 do not require further resources to complete their execution and will release the resources they are currently hold in finite time. These resources can then be allocated to P1 and P3 for them to resume their execution.
In the next lecture, we will characterize deadlocks. In other words, we will discuss the condition that must hold for a deadlock to occur. Following this we will discuss the various techniques to handle deadlocks.
