5. deadlocks

Upload: rahul-kumar

Post on 22-Feb-2018

242 views

Category:

Documents


0 download

TRANSCRIPT

  • 7/24/2019 5. Deadlocks

    1/43

    Chapter 7Chapter 7

    DeadlocksDeadlocks

  • 7/24/2019 5. Deadlocks

    2/43

    7.2 Silberschatz, Galvin and Gagne 2005Operating System Concepts - 7thEdition, Feb 14, 2005

    Chapter 7: DeadlocksChapter 7: Deadlocks

    7.1 System Model 7.2 Deadlock Characterization

    7.3 Methods for Handling Deadlocks

    7.4 Deadlock Prevention

    7.5 Deadlock Avoidance

    7.6 Deadlock Detection

    7.7 Recovery from Deadlock

  • 7/24/2019 5. Deadlocks

    3/43

    7.3 Silberschatz, Galvin and Gagne 2005Operating System Concepts - 7thEdition, Feb 14, 2005

    Chapter ObjectivesChapter Objectives

    To develop a description of deadlocks, which preventsets of concurrent processes from completing their tasks

    To present a number of different methods for preventing,avoiding, or detecting deadlocks in a computer system

  • 7/24/2019 5. Deadlocks

    4/43

    7.1 System Model7.1 System Model

  • 7/24/2019 5. Deadlocks

    5/43

    7.5 Silberschatz, Galvin and Gagne 2005Operating System Concepts - 7thEdition, Feb 14, 2005

    The Deadlock ProblemThe Deadlock Problem

    A deadlock consists of a set of blocked processes, eachholding a resource and waiting to acquire a resource held byanother process in the set

    Example #1

    A system has 2 disk drives

    P1andP2each hold one disk drive and each needs the other one

    Example #2

    SemaphoresAandB, initialized to 1

    P0 P1

    wait (A); wait(B)wait (B); wait(A)

  • 7/24/2019 5. Deadlocks

    6/43

    7.6 Silberschatz, Galvin and Gagne 2005Operating System Concepts - 7thEdition, Feb 14, 2005

    Bridge Crossing ExampleBridge Crossing Example

    Traffic only in one direction

    The resource is a one-lane bridge

    If a deadlock occurs, it can be resolved if one car backs up(preempt resources and rollback)

    Several cars may have to be backed up if a deadlock occurs

    Starvation is possible

  • 7/24/2019 5. Deadlocks

    7/437.7 Silberschatz, Galvin and Gagne 2005Operating System Concepts - 7thEdition, Feb 14, 2005

    System ModelSystem Model

    Resource typesR1,R2, . . .,Rm

    CPU cycles, memory space, I/O devices

    Each resource typeRihas1 or moreinstances

    Each process utilizes a resource as follows:

    request use

    release

  • 7/24/2019 5. Deadlocks

    8/43

    7.2 Deadlock Characterization7.2 Deadlock Characterization

  • 7/24/2019 5. Deadlocks

    9/437.9 Silberschatz, Galvin and Gagne 2005Operating System Concepts - 7thEdition, Feb 14, 2005

    Deadlock CharacterizationDeadlock Characterization

    Mutual exclusion:only one process at a time can use aresource

    Hold and wait:a process holding at least one resource iswaiting to acquire additional resources held by otherprocesses

    No preemption:a resource can be released only voluntarilyby the process holding it after that process has completed itstask

    Circular wait:there exists a set {P0,P1, ,P0} of waitingprocesses such thatP0is waiting for a resource that is held

    byP1,P1is waiting for a resource that is held byP2, ,Pn1is waiting for a resource that is held byPn, andPnis waiting for a resource that is held byP0

    Deadlock can arise if four conditions hold simultaneously.

  • 7/24/2019 5. Deadlocks

    10/437.10 Silberschatz, Galvin and Gagne 2005Operating System Concepts - 7thEdition, Feb 14, 2005

    Resource-Allocation GraphResource-Allocation Graph

    V is partitioned into two types:

    P= {P1,P2, ,Pn}, the set consisting of all

    the processes in the system

    R= {R1,R2, ,Rm}, the set consisting of allresource types in the system

    request edge directed edgeP1Rj

    assignment edge directed edgeRjPi

    A set of verticesVand a set of edgesE.

  • 7/24/2019 5. Deadlocks

    11/437.11 Silberschatz, Galvin and Gagne 2005Operating System Concepts - 7thEdition, Feb 14, 2005

    Resource-Allocation Graph (Cont.)Resource-Allocation Graph (Cont.)

    Process

    Resource Type with 4 instances

    Pirequests instance ofRj

    Piis holding an instance ofRj

    Pi

    Pi

    Rj

    Rj

  • 7/24/2019 5. Deadlocks

    12/437.12 Silberschatz, Galvin and Gagne 2005Operating System Concepts - 7thEdition, Feb 14, 2005

    Resource Allocation Graph With A DeadlockResource Allocation Graph With A Deadlock

    Before P3requested an

    instance of R2

    After P3requested an

    instance of R2

  • 7/24/2019 5. Deadlocks

    13/437.13 Silberschatz, Galvin and Gagne 2005Operating System Concepts - 7thEdition, Feb 14, 2005

    Graph With A Cycle But No DeadlockGraph With A Cycle But No Deadlock

    Process P4may release its instance of resource type R2. That

    resource can then be allocated to P3, thereby breaking the cycle.

  • 7/24/2019 5. Deadlocks

    14/437.14 Silberschatz, Galvin and Gagne 2005Operating System Concepts - 7thEdition, Feb 14, 2005

    Relationship of cycles to deadlocksRelationship of cycles to deadlocks

    If a resource allocation graph contains no cyclesno deadlock

    If a resource allocation graph contains a cycle andif only one instance exists perresource typedeadlock

    If a resource allocation graph contains a cycle and and if several instancesexists per resource typepossibility of deadlock

  • 7/24/2019 5. Deadlocks

    15/43

    7.3 Methods for Handling Deadlocks7.3 Methods for Handling Deadlocks

  • 7/24/2019 5. Deadlocks

    16/437.16 Silberschatz, Galvin and Gagne 2005Operating System Concepts - 7thEdition, Feb 14, 2005

    Methods for Handling DeadlocksMethods for Handling Deadlocks

    Prevention

    Ensure that the system willneverenter a deadlock state

    Avoidance

    Ensure that the system willneverenter an unsafe state

    Detection

    Allow the system to enter a deadlock state and then recover

    Do Nothing

    Ignore the problem and let the user or system administrator respond to the problem;

    used by most operating systems, including Windows and UNIX

  • 7/24/2019 5. Deadlocks

    17/43

    7.4 Deadlock Prevention7.4 Deadlock Prevention

  • 7/24/2019 5. Deadlocks

    18/437.18 Silberschatz, Galvin and Gagne 2005Operating System Concepts - 7thEdition, Feb 14, 2005

    Deadlock PreventionDeadlock Prevention

    Mutual Exclusion The mutual-exclusion condition musthold for non-sharable resources

    Hold and Wait we must guarantee that whenever a

    process requests a resource, it does not hold any otherresources

    Require a process to request and be allocated all its resourcesbefore it begins execution, or allow a process to requestresources only when the process has none

    Result: Low resource utilization; starvation possible

    To prevent deadlock, we can restrain the ways that a request can be made

  • 7/24/2019 5. Deadlocks

    19/437.19 Silberschatz, Galvin and Gagne 2005Operating System Concepts - 7thEdition, Feb 14, 2005

    Deadlock Prevention (Cont.)Deadlock Prevention (Cont.)

    No Preemption

    If a process that is holding some resources requests anotherresource that cannot be immediately allocated to it, then allresources currently being held are released

    Preempted resources are added to the list of resources for whichthe process is waiting

    A process will be restarted only when it can regain its oldresources, as well as the new ones that it is requesting

    Circular Wait impose a total ordering of all resource types, andrequire that each process requests resources in an increasing order ofenumeration. For example:

    F(tape drive) = 1 F(disk drive) = 5 F(printer) = 12

  • 7/24/2019 5. Deadlocks

    20/43

    7.5 Deadlock Avoidance7.5 Deadlock Avoidance

  • 7/24/2019 5. Deadlocks

    21/437.21 Silberschatz, Galvin and Gagne 2005Operating System Concepts - 7thEdition, Feb 14, 2005

    Deadlock AvoidanceDeadlock Avoidance

    Simplest and most useful model requires that each process declarethemaximum numberof resources of each type that it may need

    The deadlock-avoidance algorithm dynamically examines the

    resource-allocation state to ensure that there can never be acircular-wait condition

    A resource-allocationstateis defined by the number of availableand allocated resources, and the maximum demands of theprocesses

    Requires that the system has some additionala prioriinformationavailable.

    a priori: formed or conceived beforehand

  • 7/24/2019 5. Deadlocks

    22/437.22 Silberschatz, Galvin and Gagne 2005Operating System Concepts - 7thEdition, Feb 14, 2005

    Safe StateSafe State

    When a process requests an available resource, the system mustdecide if immediate allocation leaves the system in a safe state

    A system is in a safe state only if there exists a safe sequence

    A sequence of processes is a safe sequence for

    the current allocation state if, for each Pi, the resource requests

    that Pican still make, can be satisfied by currently available

    resources plus resources held by allPj, withj

  • 7/24/2019 5. Deadlocks

    23/437.23 Silberschatz, Galvin and Gagne 2005Operating System Concepts - 7thEdition, Feb 14, 2005

    Safe State (continued)Safe State (continued)

    If a system is in safe stateno deadlocks

    If a system is in unsafe statepossibility of deadlock

    Avoidanceensure that a system will never enter an

    unsafe state

  • 7/24/2019 5. Deadlocks

    24/43

    7.24 Silberschatz, Galvin and Gagne 2005Operating System Concepts - 7thEdition, Feb 14, 2005

    Safe, Unsafe , Deadlock StateSafe, Unsafe , Deadlock State

  • 7/24/2019 5. Deadlocks

    25/43

    7.25 Silberschatz, Galvin and Gagne 2005Operating System Concepts - 7thEdition, Feb 14, 2005

    Avoidance algorithmsAvoidance algorithms

    For a single instance of a resource type, use a resource-allocation graph

    For multiple instances of a resource type, use the bankersalgorithm

  • 7/24/2019 5. Deadlocks

    26/43

    7.26 Silberschatz, Galvin and Gagne 2005Operating System Concepts - 7thEdition, Feb 14, 2005

    Resource-Allocation Graph SchemeResource-Allocation Graph Scheme

    Introduce a new kind of edge called a claim edge

    Claim edgePi Rjindicates that processPjmayrequest resourceRj; which is represented by a dashed line

    A claim edge converts to a request edge when a processrequestsa resource

    A request edge converts to an assignment edge when theresource isallocatedto the process

    When a resource isreleasedby a process, an assignmentedge reconverts to a claim edge

    Resources must beclaimeda prioriin the system

    R All i G h ihR All ti G h ith

  • 7/24/2019 5. Deadlocks

    27/43

    7.27 Silberschatz, Galvin and Gagne 2005Operating System Concepts - 7thEdition, Feb 14, 2005

    Resource-Allocation Graph withResource-Allocation Graph with

    Claim EdgesClaim Edges

    Request

    edge

    Assignmentedge

    Claim

    edge

    Claimedge

  • 7/24/2019 5. Deadlocks

    28/43

    7.28 Silberschatz, Galvin and Gagne 2005Operating System Concepts - 7thEdition, Feb 14, 2005

    Unsafe State In Resource-Allocation GraphUnsafe State In Resource-Allocation Graph

    Assignmentedge

    Request

    edge

    AssignmentedgeClaim

    edge

  • 7/24/2019 5. Deadlocks

    29/43

    7.29 Silberschatz, Galvin and Gagne 2005Operating System Concepts - 7thEdition, Feb 14, 2005

    Resource-Allocation Graph AlgorithmResource-Allocation Graph Algorithm

    Suppose that processPirequests a resourceRj

    The request can be granted only if converting therequest edge to an assignment edge does not resultin the formation of a cycle in the resource allocation

    graph

  • 7/24/2019 5. Deadlocks

    30/43

    7.30 Silberschatz, Galvin and Gagne 2005Operating System Concepts - 7thEdition, Feb 14, 2005

    Bankers AlgorithmBankers Algorithm

    Used when there existsmultipleinstances of a resource type

    Each process musta prioriclaim maximum use

    When a process requests a resource, it may have to wait

    When a process gets all its resources, it must return them in a finite

    amount of time

  • 7/24/2019 5. Deadlocks

    31/43

    7.31 Silberschatz, Galvin and Gagne 2005Operating System Concepts - 7thEdition, Feb 14, 2005

    Data Structures for the Bankers AlgorithmData Structures for the Bankers Algorithm

    Available:Vector of lengthm. If available [j] =k, there arekinstancesof resource typeRjavailable.

    Max: n x mmatrix. IfMax[i,j] =k, then processPimay request at most

    kinstances of resource typeRj.

    Allocation: nxmmatrix. If Allocation[i,j] =kthenPiis currently

    allocatedkinstances ofRj.

    Need: nxmmatrix. IfNeed[i,j] =k, thenPimay needkmore instances

    ofRjto complete its task.

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

    Letn= number of processes, andm= number of resources types.

  • 7/24/2019 5. Deadlocks

    32/43

    7.6 Deadlock Detection7.6 Deadlock Detection

  • 7/24/2019 5. Deadlocks

    33/43

    7.33 Silberschatz, Galvin and Gagne 2005Operating System Concepts - 7thEdition, Feb 14, 2005

    Deadlock DetectionDeadlock Detection

    For deadlock detection, the system must provide

    An algorithm that examines the state of the system to detect whether adeadlock has occurred

    And an algorithm to recover from the deadlock

    A detection-and-recovery scheme requires various kinds of overhead

    Run-time costs of maintaining necessary information and executing thedetection algorithm

    Potential losses inherent in recovering from a deadlock

  • 7/24/2019 5. Deadlocks

    34/43

    7.34 Silberschatz, Galvin and Gagne 2005Operating System Concepts - 7thEdition, Feb 14, 2005

    Single Instance of Each Resource TypeSingle Instance of Each Resource Type

    Requires the creation and maintenance of await-forgraph Consists of a variant of the resource-allocation graph

    The graph is obtained byremovingthe resource nodes from aresource-allocation graph andcollapsingthe appropriateedges

    Consequently; all nodes are processes

    PiPjifPiis waiting forPj.

    Periodically invoke an algorithm that searches for a cycle inthe graph

    If there is a cycle, there exists a deadlock An algorithm to detect a cycle in a graph requires an order ofn2operations, wherenis the number of vertices in the graph

    R All i G h dW if G hR All ti G h dW itf G h

  • 7/24/2019 5. Deadlocks

    35/43

    7.35 Silberschatz, Galvin and Gagne 2005Operating System Concepts - 7thEdition, Feb 14, 2005

    Resource-Allocation Graph and Wait-for GraphResource-Allocation Graph and Wait-for Graph

    Resource-Allocation Graph Corresponding wait-for graph

  • 7/24/2019 5. Deadlocks

    36/43

    7.36 Silberschatz, Galvin and Gagne 2005Operating System Concepts - 7thEdition, Feb 14, 2005

    Multiple Instances of a Resource TypeMultiple Instances of a Resource Type

    Available:A vector of lengthmindicates the number ofavailable resources of each type.

    Allocation:Annxmmatrix defines the number of resourcesof each type currently allocated to each process.

    Request:Annxmmatrix indicates the current request ofeach process. IfRequest[ij] =k, then processPiis requesting

    kmore instances of resource type.Rj.

    Required data structures:

  • 7/24/2019 5. Deadlocks

    37/43

    7.37 Silberschatz, Galvin and Gagne 2005Operating System Concepts - 7thEdition, Feb 14, 2005

    Detection-Algorithm UsageDetection-Algorithm Usage

    When, and how often, to invoke the detection algorithm depends on:

    How often is a deadlock likely to occur?

    How many processes will be affected by deadlock when it happens?

    If the detection algorithm is invoked arbitrarily, there may bemanycyclesin the resource graph and so we would not be able to tellwhich oneof

    the many deadlocked processes caused the deadlock

    If the detection algorithm is invoked for every resource request, such anaction will incur a considerableoverheadin computation time

    A less expensive alternative is to invoke the algorithm when CPUutilization dropsbelow 40%, for example

    This is based on the observation that a deadlock eventually cripples systemthroughput and causes CPU utilization to drop

  • 7/24/2019 5. Deadlocks

    38/43

    7.7 Recovery From Deadlock7.7 Recovery From Deadlock

  • 7/24/2019 5. Deadlocks

    39/43

    7.39 Silberschatz, Galvin and Gagne 2005Operating System Concepts - 7thEdition, Feb 14, 2005

    Recovery from DeadlockRecovery from Deadlock

    Two Approaches

    Process termination

    Resource preemption

  • 7/24/2019 5. Deadlocks

    40/43

    7.40 Silberschatz, Galvin and Gagne 2005Operating System Concepts - 7thEdition, Feb 14, 2005

    Recovery from Deadlock:Recovery from Deadlock:Process TerminationProcess Termination

    Abort all deadlocked processes

    This approach will break the deadlock, but at great expense

    Abort one process at a time until the deadlock cycle is eliminated

    This approach incurs considerable overhead, since, after each process isaborted, a deadlock-detection algorithm must be re-invoked to determinewhether any processes are still deadlocked

    Many factors may affect which process is chosen for termination

    What is the priority of the process?

    How long has the process run so far and how much longer will the processneed to run before completing its task?

    How many and what type of resources has the process used? How many more resources does the process need in order to finish its task?

    How many processes will need to be terminated?

    Is the process interactive or batch?

  • 7/24/2019 5. Deadlocks

    41/43

    7.41 Silberschatz, Galvin and Gagne 2005Operating System Concepts - 7thEdition, Feb 14, 2005

    Recovery from Deadlock:Recovery from Deadlock:Resource PreemptionResource Preemption

    With this approach, we successively preempt some resources fromprocesses and give these resources to other processes until thedeadlock cycle is broken

    When preemption is required to deal with deadlocks, then threeissues need to be addressed:

    Selecting a victim Which resources and which processes are to bepreempted?

    Rollback If we preempt a resource from a process, what should bedone with that process?

    Starvation How do we ensure that starvation will not occur? That is,how can we guarantee that resources will not always be preemptedfrom the same process?

  • 7/24/2019 5. Deadlocks

    42/43

    7.42 Silberschatz, Galvin and Gagne 2005Operating System Concepts - 7thEdition, Feb 14, 2005

    SummarySummary

    Four necessary conditions must hold in the system for a deadlock

    to occur

    Mutual exclusion

    Hold and wait

    No preemption

    Circular wait

    Four principal methods for dealing with deadlocks

    Use some protocol to (1)preventor (2)avoiddeadlocks, ensuring thatthe system will never enter a deadlock state

    Allow the system to enter a deadlock state, (3)detectit,andthenrecover

    Recover byprocess terminationorresource preemption

    (4) Do nothing;ignore the problem altogether and pretend thatdeadlocks never occur in the system (used by Windows and Unix)

    To prevent deadlocks, we can ensure thatat least oneof the fournecessary conditionsnever holds

  • 7/24/2019 5. Deadlocks

    43/43

    End of Chapter 7End of Chapter 7