Top Banner
1 Concurrency: Deadlock and Concurrency: Deadlock and Starvation Starvation Chapter 6 Chapter 6
36

Concurrency: Deadlock and Starvation

Feb 24, 2016

Download

Documents

olwen

Concurrency: Deadlock and Starvation. Chapter 6. Deadlock. Permanent blocking of a set of processes Normally due to the fact that they wait for limited system resources for which they compete or wait for messages - PowerPoint PPT Presentation
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Concurrency: Deadlock and Starvation

1

Concurrency: Deadlock and StarvationConcurrency: Deadlock and Starvation

Chapter 6Chapter 6

Page 2: Concurrency: Deadlock and Starvation

2

DeadlockDeadlock

Permanent blocking of a set of processes Normally due to the fact that they

wait for limited system resources for which they compete or

wait for messages since messages can be seen as resources, in general it

can be said that it is due to contention on resources. There is no satisfactory solution in the general

case to determine whether a program contains a potential

deadlock is a computationally unsolvable problem

Page 3: Concurrency: Deadlock and Starvation

3

Leading example for this chapter:Leading example for this chapter: Consider a system that has a printer and a disk Suppose two processes P1 and P2, which behave in

the same way: Pi starts by asking for either printer or disk, but will need to

use both printer and disk later to finish Consider the following sequence of events:

P1 asks for printer, gets it P2 asks for disk, gets it Now deadlock will occur when P1 and P2 claim the second

resource they need to finish By this example, it should be clear that there can be

ways to avoid a deadlock and that if a deadlock occurs it is possible to recuperate from it

Page 4: Concurrency: Deadlock and Starvation

4

DetailsDetails

Scenario not leading to deadlock: P1 starts, takes the printer P1 takes the disk, can complete P2 now starts

We can select a good scenario if we can find out in advance: force a certain order of execution

But how to find out? Difficult: we must distinguish among waiting for a resource that will arrive and waiting for a resource that will never arrive

How to recover after detection? Possibility: suspend a process and take resources away from it

Page 5: Concurrency: Deadlock and Starvation

5

The Conditions for DeadlockThe Conditions for Deadlock

These 3 conditions of policy must be present for a deadlock to be possible (necessary conditions): 1: Mutual exclusion

only one process may use a given resource at a time 2: Hold-and-wait

a process may hold allocated resources while awaiting assignment of others

3: No preemption no resource can be forcibly removed from a process

holding it

Page 6: Concurrency: Deadlock and Starvation

6

The Conditions for DeadlockThe Conditions for Deadlock We also need the occurrence of a particular

sequence of events that result in : 4: 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, such that

• no process can complete without the resource held by the next

Page 7: Concurrency: Deadlock and Starvation

7

Relation between the 4 conditionsRelation between the 4 conditions

deadlock

mut. exclusionimplies

equivalent

circular wait

no preemption

hold and wait

Page 8: Concurrency: Deadlock and Starvation

8

Aspects of handling deadlocksAspects of handling deadlocks

Deadlock prevention disallow 1 of the 3 necessary conditions of

deadlock occurrence, or the equivalent condition

Deadlock avoidance do not grant a resource request if this

allocation might lead to deadlock Deadlock detection and recovery

always grant resource requests when possible. But periodically check for the presence of deadlock and then recover from it

Page 9: Concurrency: Deadlock and Starvation

9

Deadlock PreventionDeadlock Prevention

The OS is designed in such a way as to exclude a priori the possibility of deadlock

Indirect methods of deadlock prevention: to disallow one of the 3 policy conditions

Direct methods of deadlock prevention: to prevent the occurrence of circular wait

Page 10: Concurrency: Deadlock and Starvation

10

Indirect methods of deadlock preventionIndirect methods of deadlock prevention

Mutual Exclusion cannot be disallowed ex: only 1 process at a

time can write to a file or hold a block of memory.

Hold-and-Wait can be disallowed by

requiring that a process request all its resources at once

block the process until all requests can be granted simultaneously

but process may be held up for a long time waiting for all its requests

so resources allocated to a process may remain unused for a long time. These resources could be used by other processes

an application would need to be aware of all the resources that will be needed

Page 11: Concurrency: Deadlock and Starvation

11

Indirect methods of deadlock preventionIndirect methods of deadlock prevention

No preemption Can be prevented in several ways. But

whenever a process must release a resource whose usage is in progress, the state of this resource must be saved for later resumption.

Hence: practical only when the state of a resource can be easily saved and restored later, such as the processor.

Page 12: Concurrency: Deadlock and Starvation

12

Direct methods of deadlock preventionDirect methods of deadlock prevention A protocol to prevent circular wait:

define a strictly increasing linear ordering O() for resource types. Ex:

R1: tape drives: O(R1) = 2 R2: disk drives: O(R2) = 4 R3: printers: O(R3) = 7

A process initially requests a number of instances of a resource type, say Ri. A single request must be issued to obtain several instances.

After that, the process can request instances for resource type Rj if and only if O(Rj) > O(Rn), where Rn is a resource type already granted

Page 13: Concurrency: Deadlock and Starvation

13

Applied to our leading example...Applied to our leading example...

Deadlock cannot occur because we have decided that disk < printer,

so a process cannot ask for disk after having asked for printer

Page 14: Concurrency: Deadlock and Starvation

14

Prevention of circular waitPrevention of circular wait

Circular wait cannot hold under this protocol. In the example below, either RA<RB, or RB<RA. Suppose RA<RB. The situation below can occur because P1 has obtained RB and then requested RA, while P2 has obtained RA and then requested RB. But P1 cannot request RA after RB. There are other cases, but they are symmetrical and are excluded by the same reasoning.

Page 15: Concurrency: Deadlock and Starvation

15

Prevention of circular waitPrevention of circular wait

This protocol prevents deadlock but will often deny resources unnecessarily (inefficient) because of the ordering imposed on the requests

Page 16: Concurrency: Deadlock and Starvation

16

Deadlock Prevention: SummaryDeadlock Prevention: Summary

We disallow one of the 3 policy conditions or use a protocol that prevents circular wait

This leads to inefficient use of resources and inefficient execution of processes

Page 17: Concurrency: Deadlock and Starvation

17

Deadlock AvoidanceDeadlock Avoidance

We allow the 3 policy conditions but make judicious choices to assure that the deadlock point is never reached

Allows more concurrency than prevention Two approaches:

do not start a process if its demand might lead to deadlock

do not grant an incremental resource request if this allocation might lead to deadlock

In both cases: maximum requirements of each resource must be stated in advance

Page 18: Concurrency: Deadlock and Starvation

18

Resource allocation graphs Resource allocation graphs (Silberschatz)(Silberschatz)

Process

Resource having 4 copies (instances)

Pi asks for one instance of Ri, of which we have 4

Pj has been assigned one copy of Rj

Pi

Pi

Rj

Page 19: Concurrency: Deadlock and Starvation

19

Example of resource allocation graphs:Example of resource allocation graphs:represents a represents a statestate of the system of the system

P1 waits

P2 waits

P3 does not wait

Possible deadlock?

Page 20: Concurrency: Deadlock and Starvation

20

Resource allocation graph with deadlockResource allocation graph with deadlockCycles:

P1 R1 P2 R3 P3 R2 P1

P2 R3 P3 R2 P2

cannot get out

Page 21: Concurrency: Deadlock and Starvation

21

Allocation graph with cycle but without Allocation graph with cycle but without deadlock deadlock (why?)(why?)

Circular wait, but resources will become available

Page 22: Concurrency: Deadlock and Starvation

22

ObservationsObservations

Cycles in a resource allocation graph do not necessarily imply a circular wait

If there is no cycle in the graph, no deadlock If there are cycles:

If only one instance per resource type, deadlock If several instances, possibility of deadlock

must ask question: is there a process that can terminate and if so, which other processes can terminate as a consequence?

Page 23: Concurrency: Deadlock and Starvation

23

Safe stateSafe state A state is safe if the system can get out of it

without deadlock In a safe state we can identify a sequence of process

terminations, leading to a state where all processes terminate

Do not allocate a resource to a process if the resulting state is not safe

Page 24: Concurrency: Deadlock and Starvation

24

Deadlock detectionDeadlock detection

The system is allowed to enter a deadlock state

Deadlock is detected There is recovery from deadlock Detection of deadlock is not obvious:

if the OS sees some processes that wait, it cannot conclude that there is deadlock

there is deadlock only if there is a circular wait from which it is impossible to get out

Page 25: Concurrency: Deadlock and Starvation

25

Resource allocation graph and wait graphResource allocation graph and wait graph

The second graph can be obtained from the first one

Is there deadlock?

Page 26: Concurrency: Deadlock and Starvation

28

Resource typesResource types

Resources in a system are partitioned in resources types

Each resource type in a system exists with a certain amount. Let R(i) be the total amount of resource type i present in the system. Ex: R(main memory) = 128 MB R(disk drives) = 8 R(printers) = 5

The partition is system specific (ex: printers may be further partitioned...)

Page 27: Concurrency: Deadlock and Starvation

29

Symbol summary for this sectionSymbol summary for this section

R(i) total amount of resource i in system V(i) total available amount of resource i W(i) temporary vector: available vector U(i) total unclaimed amount of resource i C(k,i) total claim of res. i by process k A(j,i) amount of res. i allocated to proc. j N(j,i) amount of res. i needed by proc. j Q(j,i) amt. of res. i currently req. by proc j

Page 28: Concurrency: Deadlock and Starvation

41

Deadlock DetectionDeadlock Detection

Resource access are granted to processes whenever possible. The OS needs: an algorithm to check if deadlock is present an algorithm to recover from deadlock

The deadlock check can be performed at every resource request

Such frequent checks consume CPU time

Page 29: Concurrency: Deadlock and Starvation

42

Trivial example of detection in our leading Trivial example of detection in our leading exampleexample After each process has obtained 1M, the

need of each process exceeds available memory (0M!). So no process can complete and there is a deadlock between P1 and P2.

Page 30: Concurrency: Deadlock and Starvation

43

A deadlock detection algorithmA deadlock detection algorithm Makes use of previous resource-allocation

matrices and vectors Marks each process not deadlocked. Initially

all processes are unmarked. Then perform: Mark each process j for which: A(j,i) = 0 for all

resource type i. (since these are not deadlocked) Initialize work vector: W(i) = V(i) for all i REPEAT

Find an unmarked process j such that Q(j,i) <= W(i) for all i. Stop if such j does not exist.

If such j exists: mark process j and setW(i) = W(i) + A(j,i) for all i // Hoping that j will terminate

At the end: each unmarked process is deadlocked

Page 31: Concurrency: Deadlock and Starvation

44

Deadlock detection: commentsDeadlock detection: comments Process j is not deadlocked when Q(j,i) <= W(i)

for all i. Then we are optimistic and assume that

process j will require no more resources to complete its task

It will thus soon return all of its allocated resources. Thus: W(i) = W(i) + A(j,i) for all i

If this assumption is incorrect, a deadlock may occur later

This deadlock will be detected the next time the deadlock detection algorithm is invoked

Page 32: Concurrency: Deadlock and Starvation

45

Deadlock detection: exampleDeadlock detection: example

Mark P4 since it has no allocated resources Set W = (0,0,0,0,1) P3’s request <= W. So mark P3 and set W =

W + (0,0,0,1,0) = (0,0,0,1,1) Algorithm terminates. P1 and P2 are

deadlocked

R1 R2 R3 R4 R5

P1P2P3P4

Request Allocated Available

R1 R2 R3 R4 R5 R1 R2 R3 R4 R5

0 1 0 0 10 0 1 0 10 0 0 0 11 0 1 0 1

1 0 1 1 01 1 0 0 00 0 0 1 00 0 0 0 0

0 0 0 0 1

Page 33: Concurrency: Deadlock and Starvation

46

Deadlock Recovery: Deadlock Recovery: after deadlock has been detectedafter deadlock has been detected

Needed when deadlock is detected. The following approaches are possible: Abort all deadlocked processes (one of the

most common solutions adopted in OS!!) Rollback each deadlocked process to some

previously defined checkpoint and restart them (original deadlock may reoccur)

Successively abort deadlock processes until deadlock no longer exists (each time we need to invoke the deadlock detection algorithm)

Page 34: Concurrency: Deadlock and Starvation

47

Deadlock Recovery (cont.)Deadlock Recovery (cont.)

Successively preempt some resources from processes and give them to other processes until deadlock no longer exists

a process that has a resource preempted must be rolled back prior to its acquisition

For the 2 last approaches: a victim process needs to be selected according to (for ex.): least amount of CPU time consumed so far least total resources allocated so far least amount of “work” produced so far...

Page 35: Concurrency: Deadlock and Starvation

48

An integrated deadlock strategyAn integrated deadlock strategy

We can combine the previous approaches into the following way: Group resources into a number of different

classes and order them. Ex: Swappable space (secondary memory) Process resources (I/O devices, files...) Main memory...

Use prevention of circular wait to prevent deadlock between resource classes

Use the most appropriate approach for each class for deadlocks within each class

Page 36: Concurrency: Deadlock and Starvation

49

Important concepts of Chapter 6Important concepts of Chapter 6

What is deadlock, what are its causes Circular wait Necessary conditions Deadlock prevention: methods Deadlock avoidance: methods Deadlock detection: methods Resource allocation graphs Wait graphs