slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
DEADLOCKS PowerPoint Presentation
Download Presentation
DEADLOCKS

Loading in 2 Seconds...

play fullscreen
1 / 104

DEADLOCKS - PowerPoint PPT Presentation


  • 131 Views
  • Uploaded on

DEADLOCKS. Introduction. In a computer system, we have a finite number of resources to be distributed among a number of competing processes. System resources are classified into: Physical Resources Logical Resources. Introduction continue….

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

DEADLOCKS


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
introduction
Introduction
  • In a computer system, we have a finite number of resources to be distributed among a number of competing processes.
  • System resources are classified into:
  • Physical Resources
  • Logical Resources
introduction continue
Introduction continue…
  • In a computer system, we have a finite number of resources to be distributed among a number of competing processes.
  • System resources are classified into:
  • Physical Resources
  • Logical Resources
  • Printers
  • Tape drivers
  • Memory space
  • CPU cycles
slide4

Introduction continue…

  • In a computer system, we have a finite number of resources to be distributed among a number of competing processes.
  • System resources are classified into:
  • Physical Resources
  • Logical Resources
  • Files
  • Semaphores
slide5

Introduction continue…

A process must request a resource before using it and release the resource after using it.

The number of resources requested can not exceed the total number of resources available in the system.

slide6

Introduction continue…

  • In a normal operation, a process may utilize a resource in the following sequence:
  • Request the resource
  • Use the resource
  • Release the resource
slide7

Introduction continue…

  • In a normal operation, a process may utilize a resource in the following sequence:
  • Request
  • Use
  • Release

If the request can not be immediately granted, then the requesting process must wait until it can get the resource.

slide8

Introduction continue…

  • In a normal operation, a process may utilize a resource in the following sequence:
  • Request
  • Use
  • Release

The requesting process can operate on the resource.

slide9

Introduction continue…

  • In a normal operation, a process may utilize a resource in the following sequence:
  • Request
  • Use
  • Release

The process releases the resource after using it.

slide10

Introduction continue…

The OS is responsible for making sure that the requesting process has been allocated the resource. Request and release of resources can be accomplished through the wait and signal operations on semaphores. A system table records whether each resource is free or allocated, and if allocated, to which process. If a process requests a resource that is currently allocated to another process, it can be added to a queue of processes waiting for this resource.

slide11

Deadlock Situation

In a multi-programming environment, several processes may compete for a fixed number of resources. A process requests resources and if the resources are not available at that time, it enters a wait state. Waiting processes may never again change state, because the resources they have requested are held by other waiting processes. This situation is called deadlock.

slide12

Deadlock Situation

P 1

Printer

P 2

Scanner

slide13

Deadlock Situation

Consider a system with one printer and one scanner. Process P1 request the printer and process P2 requests the scanner. Both requests are granted. Now P1 requests the scanner (without giving up the printer) and P2 requests the printer (without giving up the scanner). Neither request can be granted so both processes enter a deadlock situation.

slide14

Deadlock Situation

P 1

Printer

P 2

Scanner

slide15

Deadlock - Definition

A deadlock is a situation where a group of processes is permanently blocked as a result of each process having acquired a set of resources needed for its completion and having to wait for release of the remaining resources held by others thus making it impossible for any of the deadlocked processes to proceed. Deadlocks can occur in concurrent environments as a result of the uncontrolled granting of the system resources to the requesting processes.

slide16

Deadlock - Definition

A set of process is in a deadlock state if each process in the set is waiting for an event that can be caused by only another process in the set.

Each member of the set of deadlock processes is waiting for a resource that can be released only by a deadlock process.

slide17

Deadlock Characterization

  • Necessary Conditions
  • A deadlock situation can arise if the following four conditions hold simultaneously in a system.
    • Mutual Exclusion
    • Hold and Wait
    • No Preemption
    • Circular Wait
slide18

Deadlock Characterization

  • Necessary Conditions Continue…
  • 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.
slide19

Deadlock Characterization

  • Necessary Conditions Continue…
  • Hold and Wait
  • A process must be holding at least one resource and waiting to acquire additional resources that are currently held by other processes.
slide20

Deadlock Characterization

  • Necessary Conditions Continue…
  • No Preemption
  • Resources already allocated to a process cannot be preempted; that is, a resource can be released only voluntarily by the process holding it, after process has completed its task.
slide21

Deadlock Characterization

  • Necessary Conditions Continue…
  • Circular Wait
  • A set {P0, P1, …, Pn} of waiting processes must exist such that P0 is waiting for a resource that is held by P1, P1 is waiting for a resource that is held by P2, …, Pn-1 is waiting for a resource that is held by Pn, and Pn is waiting for a resource that is held by P0.
  • The processes in the system form a circular list or chain where each process in the list is waiting for a resource held by the next process in the list.
slide22

Deadlock Situation

P 1

P 2

P 1

i

i

R1

R2

P 2

i

i

R1

R2

Holding a resource

Requesting a resource

Deadlock situation

Graphic representation of Resource Allocation

slide23

Resource-Allocation Graph

Resource-allocation graph is used to described the deadlock.

This graph consists of a set of vertices V and a set of edges E. The set vertices V is partitioned into two different types of nodes P = {P1, P2, …, Pn}, the set consisting of all active processes in the system, and R = {R1, R2, …, Rm}, the set consisting of all resource types in the system.

slide24

Resource-Allocation Graph continue…

A directed edge from resource type Rj to process Pi is denoted by RjgPi ; it signifies that an instance of resource type Rj has been allocated to process Pi .

A directed edge PigRj is called a request edge and

a directed edge RjgPi is called an assignment edge.

slide25

Resource-Allocation Graph continue…

Process node is represented by circles.

Resource node is represented by rectangles.

For each instances of a resource type, there is a dot in the resource node rectangle.

P 1

R1

i

i

R2

slide26

Resource-Allocation Graph continue…

A request edge points to only the square , where as an assignment edge must also designate one of the dots in the square.

i

i

R1

R3

P 1

P 2

P 3

i

i

i

i

i

R2

R4

slide27

Resource-Allocation Graph continue…

When process Pi requests an instance of resource type Rj, a request edge is inserted in the resource allocation graph.

i

i

R1

R3

P 1

P 2

P 3

i

i

i

i

i

R2

R4

slide28

Resource-Allocation Graph continue…

When this requests can be fulfilled the request edge is instantaneously transformed to an assignment edge.

i

i

R1

R3

P 1

P 2

P 3

i

i

i

i

i

R2

R4

slide29

Resource-Allocation Graph continue…

When the process no longer needs access to the resource it releases the resource, and as a result the assignment edge is deleted.

i

i

R1

R3

P 1

P 2

P 3

i

i

i

i

i

R2

R4

slide30

Resource-Allocation Graph continue…

The resource-allocation graph depicts the following:

i

i

R1

R3

P 1

P 2

P 3

  • The sets P, R, and E
  • P = {P1, P2, …, Pn}
  • R = {R1, R2, …, Rm}
  • E = {P1gR1, P2gR3, R1gP2, R2gP2, R2gP1, R3gP3}

i

i

i

i

i

R2

R4

slide31

Resource-Allocation Graph continue…

The resource-allocation graph depicts the following:

i

i

R1

R3

P 1

P 2

P 3

  • Resource instances
  • One instance of resource type R1
  • Two instances of resource type R2
  • One instance of resource type R3
  • Three instances of resource type R4

i

i

i

i

i

R2

R4

slide32

Resource-Allocation Graph continue…

The resource-allocation graph depicts the following:

Process states

i

i

R1

R3

Process P1 is holding an instance of resource type R2 , and is waiting for an instance of resource type R1 .

P 1

P 2

P 3

i

i

i

i

i

R2

R4

slide33

Resource-Allocation Graph continue…

The resource-allocation graph depicts the following:

Process states

i

i

R1

R3

Process P1 is holding an instance of resource type R2, and is waiting for an instance of resource type R1.

Process P2 is holding an instance of resource types R1 and R2, and is waiting for an instance of resource type R3 .

P 1

P 2

P 3

i

i

i

i

i

R2

R4

slide34

Resource-Allocation Graph continue…

The resource-allocation graph depicts the following:

Process states

i

i

R1

R3

Process P1 is holding an instance of resource type R2, and is waiting for an instance of resource type R1.

Process P2 is holding an instance of resource types R1 and R2, and is waiting for an instance of resource type R3 .

P 1

P 2

P 3

Process P3 is holding an instance of resource type R3 .

i

i

i

i

i

R2

R4

slide35

Resource-Allocation Graph continue…

Tips to check deadlock:

i

i

R1

R3

If no cycle exists in the resource allocation graph, there is no deadlock.

P 1

P 2

P 3

i

i

i

i

i

R2

R4

slide36

Resource-Allocation Graph continue…

Tips to check deadlock:

i

i

R1

R3

If there is a cycle in the graph and each resource has only one instance, then there is a deadlock. Here a cycle is a necessary and sufficient condition for deadlock.

P 1

P 2

P 3

i

i

i

i

R2

R4

slide37

Resource-Allocation Graph continue…

Tips to check deadlock:

If there is a cycle in the graph and each resource has more than one instance, there may or may not be a deadlock. A cycle may be broken if some process outside the cycle has a resource instance that can break the cycle. Therefore, a cycle in the resource allocation graph is a necessary but not sufficient condition for deadlock, when multiple resource instances are considered.

slide38

Resource-Allocation Graph continue…

Tips to check deadlock:

P 2

i

i

R1

If there is a cycle in the graph and each resource has more than one instance, there may or may not be a deadlock. A cycle may be broken if some process outside the cycle has a resource instance that can break the cycle. Therefore, a cycle in the resource allocation graph is a necessary but not sufficient condition for deadlock, when multiple resource instances are considered.

P 1

P 3

i

i

P 4

R2

slide39

Handling Deadlocks

Possible strategies to deal with deadlocks:

  • Deadlock Prevention
  • Deadlock Avoidance
  • Deadlock Detection and Recovery
slide40

Handling Deadlocks continue…

Possible strategies to deal with deadlocks:

  • Deadlock Prevention
  • Deadlock Avoidance
  • Deadlock Detection and Recovery

Is a set methods for ensuring that at least one of the necessary conditions cannot hold. These methods prevent deadlocks by constraining how requests for resources can be made.

slide41

Handling Deadlocks continue…

Possible strategies to deal with deadlocks:

  • Deadlock Prevention
  • Deadlock Avoidance
  • Deadlock Detection and Recovery

DA requires that the operating system be given in advance additional information concerning which resources a process will request and use during its lifetime. With this knowledge, we can decide for each request whether or not the process should wait.

slide42

Handling Deadlocks continue…

Possible strategies to deal with deadlocks:

  • Deadlock Prevention
  • Deadlock Avoidance
  • Deadlock Detection and Recovery

Here the system can provide an algorithm that examines the state of the system to determine whether a deadlock has occurred and an algorithm to recover from the deadlock.

slide43

Deadlock Prevention

We can prevent the occurrence of a deadlock by ensuring that at least one of the four necessary conditions can not hold.

  • Mutual Exclusion
  • Hold and Wait
  • No Preemption
  • Circular Wait
slide44

Deadlock Prevention continue…

Mutual Exclusion:

Shareable resources do not require mutually exclusive access, and thus cannot be involved in a deadlock.

slide45

Deadlock Prevention continue…

Hold and Wait:

When a process requests a resource, it does not hold any other resources. Two protocols:

  • Requires each process to request and be allocated all its resources before it begins execution.
  • Allows a process to request resources only when the process has none.
slide46

Deadlock Prevention continue…

Hold and Wait:

When a process requests a resource, it does not hold any other resources. Two protocols:

  • Requires each process to request and be allocated all its resources before it begins execution.
  • Allows a process to request resources only when the process has none.

A process may request some resources and use them. However it must release all the resources that is currently allocated before it can request any additional resources.

slide47

Deadlock Prevention continue…

No Preemption:

If a process is holding some resources and requests another resource that cannot be immediately allocated to it, then all resources currently being held are preempted. The process will be restarted only when it can regain its old resources, as well as the new ones that is requesting.

slide48

Deadlock Prevention continue…

No Preemption:

If a process requests some resources, we first check whether they are available. If they are, we allocate them. If they are not available, we check whether they are allocated to some other process that is waiting for additional resources. If so, we preempt the desired resources from the waiting process and allocate them to the requesting process. If the resources are not either available or held by a waiting process, the requesting process must wait. While it is waiting, some of its resources may be preempted, but only if another process request them. A process can be restarted only when it is allocated the new resources it is requesting and recovers any resources that were preempted while it was waiting.

slide49

Deadlock Prevention continue…

Circular Wait:

One way to ensure that circular wait never holds is to impose a total ordering of all resource types, and to require that each process requests resources in an increasing order of enumeration.

slide50

Deadlock Prevention continue…

Circular Wait:

Each process can request resources only in an increasing order of enumeration. That is, a process can initially request any number of instances of a resource type, say Ri. After that, the process can request instances of resource type Rj if and onlyif F(Rj) > F(Ri).

slide51

Deadlock Prevention continue…

Circular Wait:

Alternatively, whenever a process requests an instance of resource type Rj, it has released any resources Ri such that F(Ri) >= F(Rj).

slide52

Deadlock Prevention continue…

Deadlock prevention algorithms prevent deadlocks by restraining how request can be made. This ensures that at least one of the necessary conditions for deadlock cannot occur. Possible side effects of preventing deadlocks by this methods are low utilization and reduced system throughput.

slide53

Deadlock Avoidance

Deadlock-Allocation requires that the operating system be given in advance additional information concerning which resources a process will request and use during its lifetime. With this knowledge, we can decide for each request whether or not the process should wait.

slide54

Deadlock Avoidance

Deadlock-Allocation requires that the operating system be given in advance additional information concerning which resources a process will request and use during its lifetime. With this knowledge, we can decide for each request whether or not the process should wait.

Given a priori information about the maximum number of resources of each type that may be requested for each process, it is possible to construct an algorithm that ensures the deadlock-avoidance approach.

slide55

Deadlock Avoidance

Deadlock-Allocation requires that the operating system be given in advance additional information concerning which resources a process will request and use during its lifetime. With this knowledge, we can decide for each request whether or not the process should wait.

Given a priori information about the maximum number of resources of each type that may be requested for each process, it is possible to construct an algorithm that ensures the deadlock-avoidance approach.

A deadlock-avoidance algorithm dynamically examines the resource-allocation state to ensure that a circular wait condition can never exist. The resource-allocation state is defined by the number of available and allocated resources, and the maximum demands of the processes.

slide56

Deadlock Avoidance continue…

Safe State

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. A system is in a safe state only if there exists a safe sequence.

slide57

Deadlock Avoidance continue…

Safe State

A sequence of processes <P1, P2, …, Pn> is a safe sequence for the current allocation state if, for each Pi, the resources that Pi can still request can be satisfied by the currently available resources plus the resources held by all the Pj, with j < i.

slide58

Deadlock Avoidance continue…

Safe State

In this situation the resources that process Pi needs are not immediately available, then Pi can wait until all Pj have finished. When they have finished, Pi can obtain all of its needed resources, complete its designated task, return its allocated resources and terminate. When Pi terminates, Pi+1 can obtain its needed resources and so on. If no sequence exists, then the system state is said to be unsafe.

slide59

Deadlock Avoidance continue…

Safe State

Consider a system with 12 magnetic tape drives and 3 processes, P0, P1 and P2.

Maximum need To

P0 10 5

P1 4 2

P2 9 2

slide60

Deadlock Avoidance continue…

Safe State

Consider a system with 12 magnetic tape drives and 3 processes, P0, P1 and P2.

Maximum need To

P0 10 5

P1 4 2

P2 9 2

At time To, the system is in a safe state

slide61

Deadlock Avoidance continue…

Safe State

Now there are 3 free tape drives.

The sequence <P1, P0, P2> satisfies the safety condition.

Process P1 can immediately be allocated all its tape drives and then return them(the system then will have 5 available tape drives), then process P0 can get all its tape drives and return them(then available – 10 tape drives), and finally process P2 could get all its tape drives.

slide62

Deadlock Avoidance continue…

Safe State

A system may go from a safe state to an unsafe state.

Suppose that at time T1, process P2 requests and is allocated 1 more tape drive. Then the system is no longer in a safe state, because at this point only process P1 can be allocated all its tape drives and process P0 and P2 have to wait – resulting in a deadlock.

slide63

Deadlock Avoidance continue…

Safe State

Avoidance algorithms 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 system must decide whether the resource can be allocated immediately or whether the process must wait. The request is granted only if the allocation leaves the system in safe state.

slide64

Deadlock Avoidance continue…

Safe State

Avoidance algorithms 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 system must decide whether the resource can be allocated immediately or whether the process must wait. The request is granted only if the allocation leaves the system in safe state.

slide65

Deadlock Avoidance continue…

Safe State

In this scheme, if a process requests a resource that is currently available, it may still have to wait. Thus, resource utilization may be lower than it would be without deadlock-avoidance algorithm.

slide66

i

i

i

Deadlock Avoidance continue…

Resource-Allocation Graph Algorithm

This graph has three types of edges:

  • Request edge
  • Assignment edge
  • Claim edge
  • A claim edge PigRj indicates that the process Pimay request resource Rj at some time in the future.
slide67

Deadlock Avoidance continue…

Resource-Allocation Graph Algorithm

When process Pi request resource Rj, the claim edge PigRj is converted to a request edge. When the resource Rj is released by Pi, the assignment edge RjgPi is converted to a claim edge PigRj.

Before process Pistarts executing, all its claim edges must appear in the resource-allocation graph.

slide68

Deadlock Avoidance continue…

Resource-Allocation Graph Algorithm

Suppose, process Pirequests resource Rj. The request can be granted only if converting the request edge PigRj to an assignment edge RjgPi does not result in the formation of a cycle in the resource-allocation graph.

Safety is provided by the use of cycle detection algorithm.

slide69

Deadlock Avoidance continue…

Resource-Allocation Graph Algorithm

i

R1

If P2 requests R2, we cannot allocate it to P2 even if R2 is currently free, since this action will create a cycle in the graph.

P 1

P 2

i

R2

slide70

R1

i

P 1

P 2

i

R2

Deadlock Avoidance continue…

Resource-Allocation Graph Algorithm

i

R1

If P2 requests R2, we cannot allocate it to P2 even if R2 is currently free, since this action will create a cycle in the graph.

P 1

P 2

i

R2

slide71

Banker’s Algorithm

Resource-Allocation Graph Algorithm is not applicable to a resource allocation system with multiple instances of each resource type.

Banker’s Algorithm deals multiple instances of each resource type.

This algorithm could be used in a banking system to ensure that the bank never allocates its available cash such that it can no longer satisfy the needs of all its customers.

slide72

Banker’s Algorithm continue…

When a new process enters the system, it must declare the maximum number of instances of each resource type that it may need. This number may not exceed the total number resources in the system.

slide73

Banker’s Algorithm continue…

When a user requests a set of resources, the system must determine whether the allocation of these resources will leave the system in a safe state. If it will, the resources are allocated; otherwise, the process must wait until some other process releases enough resources.

slide74

Banker’s Algorithm continue…

To implement Banker’s algorithm, we need the following data structures:

  • Available
  • Max
  • Allocation
  • Need
slide75

Banker’s Algorithm continue…

To implement Banker’s algorithm, we need the following data structures:

  • Available
  • Max
  • Allocation
  • Need

A vector of length m indicates the number of available resources of each type. If Available[j] = k, there are k instances of resource type Rj available.

slide76

Banker’s Algorithm continue…

To implement Banker’s algorithm, we need the following data structures:

  • Available
  • Max
  • Allocation
  • Need

An n x m matrix defines the maximum demand of each process. If max[i,j] = k, then process Pi may request at most k instances of resource type Rj.

slide77

Banker’s Algorithm continue…

To implement Banker’s algorithm, we need the following data structures:

  • Available
  • Max
  • Allocation
  • Need

An n x m matrix defines the number of resources of each type currently allocated to each process. If Allocation[i,j] = k, then process Pi is currently allocated k instances of resource type Rj.

slide78

Banker’s Algorithm continue…

To implement Banker’s algorithm, we need the following data structures:

  • Available
  • Max
  • Allocation
  • Need

An n x m matrix indicates the remaining resource need of each process. If Need[i, j] = k, then process Pi may need k more instances of resource type Rj to complete its tasks.

Need[i,j] = Max[i,j] – Allocation[i,j].

slide79

Banker’s Algorithm continue…

We can treat each row in the matrices Allocation and Need as vectors and refer to them as Allocationi and Needi. The vector Allocationispecifies the resources currently allocated to process Pi; the vector Needi specifies the additional resources that process Pi may still request to complete its task.

slide80

Banker’s Algorithm continue…

Resource-Request Algorithm:

Let Requesti be the request vector for process Pi. If Requesti[j] = k, then process Pi wants k instances of resource type Rj. When a request for resources is made by process Pi, the following actions are taken:

slide81

Banker’s Algorithm continue…

Resource-Request Algorithm: continue…

  • If Requesti ≤ Needi, go to step 2. Otherwise, raise an error condition, since the process has exceeded it maximum claim.
  • If Requesti≤ Available, go to step 3. Otherwise, Pi must wait, since the resources are not available.
  • Pretend to have allocated the requested resources to process Pi by modifying the state as follows:
    • Available := Available – Requesti;
    • Allocationi := Allocationi + Requesti;
    • Needi := Needi – Requesti;
slide82

Banker’s Algorithm continue…

Resource-Request Algorithm: continue…

If the resulting resource-allocation state is safe, the transaction is completed and process Pi is allocated its resources. However, if the new state is unsafe, then Pi must wait for Requesti and the old resource-allocation state is restored.

slide83

Banker’s Algorithm continue…

Safety Algorithm:

  • Let Work and Finish be vectors of length m and n respectively. Initialize Work := Available and Finish[i] := false for i=1,2, …, n.
  • Find an i such that both
    • Finish[i] = false
    • Needi ≤ Work.
    • If no such i exists, go to step 4.
  • Work := Work + Allocationi

Finish[i] := true;

Go to step 2.

  • If Finish[i] = true for all i, then the system is an a safe state.
slide84

Deadlock Detection

If a system does not employ either a deadlock-prevention or a deadlock avoidance algorithm, then it should provide:

  • An algorithm that examines the state of the system to determine whether a deadlock has occurred.
  • An algorithm to recover from the deadlock.
slide85

Deadlock Detection continue…

Single Instance of Each Resource Type

If all resources have only a single instance, then we can define a deadlock detection algorithm that uses a variant of the resource-allocation graph, called a wait-for graph.

We obtain this graph from the resource-allocation graph by removing the resource nodes and collapsing the appropriate edges.

slide86

Deadlock Detection continue…

Single Instance of Each Resource Type

(a) Resource-allocation graph (b) Corresponding wait-for graph

slide87

Deadlock Detection continue…

Single Instance of Each Resource Type

An edge from Pi to Pj in a wait-for graph implies that process Pi is waiting for process Pj to release a resource that Pi needs.

An edge PigPj exists in a wait-for graph if and only if the corresponding resource-allocation graph contains two edges PigRq and RqgPj for some resource Rq.

slide88

Deadlock Detection continue…

Single Instance of Each Resource Type

If there exists a cycle in wait-for graph, there is a deadlock in the system, and the processes forming the part of cycle are blocked in the deadlock. To take appropriate action to recover from this situation, an algorithm needs to be called periodically to detect existence of cycle in wait-for graph.

slide89

Deadlock Detection continue…

Multiple Instances of a Resource Type

When multiple instances of a resource type exist, the wait-for graph becomes inefficient to detect the deadlock in the system.

An algorithm which uses certain data structures similar to ones used in Banker’s algorithm is applied.

slide90

Deadlock Detection continue…

  • Multiple Instances of a Resource Type

The following data structures are used:

  • Available Resources
  • Current Allocation
  • Request
slide91

Deadlock Detection continue…

  • Multiple Instances of a Resource Type

The following data structures are used:

  • Available Resources, A: A vector of size q stores information about the number of available resources of each type.
  • Current Allocation
  • Request
slide92

Deadlock Detection continue…

  • Multiple Instances of a Resource Type

The following data structures are used:

  • Available Resources
  • Current Allocation, C: A matrix of order pxq stores information about the number of resources of each type allocated to each process. C[i][j] indicates the number of resources of type j currently held by the process i.
  • Request
slide93

Deadlock Detection continue…

  • Multiple Instances of a Resource Type

The following data structures are used:

  • Available Resources
  • Current Allocation
  • Request, R: A matrix of order pxq stores information about the number of resources of each type currently requested by each process. R[i][j] indicates the number of resources of type j currently requested by the process i.
slide94

Deadlock Detection continue…

Multiple Instances of a Resource Type

Consider a vector Complete of size p.

Steps to detect the deadlock:

Initialize Complete[i]=False for all i=1,2,3, …., p. Complete[i]=False indicates that the ith process is still not completed.

Search for an i, such that Complete[i]=False and (R<=A), that is , resources currently requested by this process is less than the available resources. If no such process exists, then go to step 4.

slide95

Deadlock Detection continue…

Multiple Instances of a Resource Type

Allocate the required resources and let the process finish its execution and set Complete[i]=True for that process. Go to Step 2.

If Complete[i]=False for some i, then the system is in the state of deadlock and the ith process is deadlocked.

slide96

Deadlock Recovery

  • When a detection algorithm determines that a deadlock exists, then:
  • let the operator deal with the deadlock manually.
  • let the system recover from the deadlock automatically.
  • There are two options for breaking a deadlock:
  • to abort one or more processes to break the circular wait.
  • to preempt some resources from one or more of the deadlocked processes.
slide97

Deadlock Recovery continue…

  • Process Termination:
  • There are two methods that can be used for terminating the processes to recover from the deadlock:
  • Terminating one process at a time until the circular-wait condition is eliminated.
  • Terminating all processes involved in the deadlock.
slide98

Deadlock Recovery continue…

It involves an over head of invoking a deadlock detection algorithm after terminating each process to detect whether circular-wait condition is eliminated or not, that is, whether any processes are still deadlocked.

  • Process Termination:
  • There are two methods that can be used for terminating the processes to recover from the deadlock:
  • Terminating one process at a time until the circular-wait condition is eliminated.
  • Terminating all processes involved in the deadlock.
slide99

Deadlock Recovery continue…

  • Process Termination:
  • There are two methods that can be used for terminating the processes to recover from the deadlock:
  • Terminating one process at a time until the circular-wait condition is eliminated.
  • Terminating all processes involved in the deadlock.

This method will definitely ensure the recovery of a system from the deadlock. The disadvantage of this method is that many processes may have executed for a long time; close to their completion. As a result, the computations performed till the time of termination are discarded.

slide100

Deadlock Recovery continue…

Resource Preemption:

An alternate method to recover system from the state of deadlock is to preempt the resources from the processes one by one and allocate them to other processes until the circular-wait condition is eliminated.

slide101

Deadlock Recovery continue…

  • Resource Preemption:
  • Steps involved in the preemption of resources from processes are:
  • Select a process for preemption.
  • Roll back of the process.
  • Prevent starvation.
slide102

Deadlock Recovery continue…

  • Resource Preemption:
  • Steps involved in the preemption of resources from processes are:
  • Select a process for preemption.
  • Roll back of the process.
  • Prevent starvation.

The choice of resources and processes must be such that they incur minimum cost to the system.

slide103

Deadlock Recovery continue…

After preempting the resources, the corresponding process must be rolled backed properly so that it does not leave the system in an inconsistent state. Process must be brought to some safe state from where it can be restarted later. In case no such safe state can be achieved, the process must be totally rolled back. Partial rollback is preferred.

  • Resource Preemption:
  • Steps involved in the preemption of resources from processes are:
  • Select a process for preemption.
  • Roll back of the process.
  • Prevent starvation.
slide104

Deadlock Recovery continue…

  • Resource Preemption:
  • Steps involved in the preemption of resources from processes are:
  • Select a process for preemption.
  • Roll back of the process.
  • Prevent starvation.

In case of the selection of a process is based on the cost factor, it is quite possible that same process is selected repeatedly for the rollback leading to the situation of starvation. This can be avoided by including the number of rollbacks of a given process in the cost factor.