Operating System Concepts - PowerPoint PPT Presentation

1 / 56
About This Presentation
Title:

Operating System Concepts

Description:

Operating System Concepts Ku-Yaw Chang canseco_at_mail.dyu.edu.tw Assistant Professor, Department of Computer Science and Information Engineering Da-Yeh University – PowerPoint PPT presentation

Number of Views:60
Avg rating:3.0/5.0
Slides: 57
Provided by: IBM7185
Category:

less

Transcript and Presenter's Notes

Title: Operating System Concepts


1
Operating System Concepts
  • Ku-Yaw Chang
  • canseco_at_mail.dyu.edu.tw
  • Assistant Professor, Department of Computer
    Science and Information Engineering
  • Da-Yeh University

2
Chapter 8 Deadlocks
  • In a multiprogramming environment
  • Several processes may compete for a finite number
    of resources
  • A process requests resources
  • If no available, the process enter a wait state.
  • Waiting process may never again change state
  • Such a situation is called a deadlock
  • A law passed by the Kansas legislature
  • When two trains approach each other at a
    crossing, both shall come to a full stop and
    neither shall start up again until the other has
    gone.

3
Chapter 8 Deadlocks
  1. System Model
  2. Deadlock Characterization
  3. Methods for Handling Deadlocks
  4. Deadlock Prevention
  1. Deadlock Avoidance
  2. Deadlock Detection
  3. Recovery from Deadlock
  4. Summary
  5. Exercises

4
8.1 System Model
  • A process may utilize a resource in only the
    following sequence
  • Request
  • If this request cannot be granted immediately,
    the requesting process must wait.
  • Use
  • Release
  • Examples
  • open and close file system calls
  • allocate and free memory system calls

5
Deadlock State
  • A set of processes is in a deadlock state when
    every process in the set is waiting for an event
    that can be caused only by another process in the
    set.
  • Resources
  • Physical resources
  • printers, tape drives, memory space, CPU
  • Logical resources
  • files, semaphores, monitors
  • Other types of events
  • IPC facilities

6
Deadlock Examples
  • Example
  • System has 2 tape drives.
  • P1 and P2 each hold one tape drive and each needs
    another one.
  • Example
  • semaphores A and B, initialized to 1
  • P0 P1
  • wait (A) wait (B)
  • wait (B) wait (A)

7
Bridge Crossing Example
  • Traffic only in one direction.
  • Each section of a bridge can be viewed as a
    resource.
  • 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.

8
Chapter 8 Deadlocks
  1. System Model
  2. Deadlock Characterization
  3. Methods for Handling Deadlocks
  4. Deadlock Prevention
  1. Deadlock Avoidance
  2. Deadlock Detection
  3. Recovery from Deadlock
  4. Summary
  5. Exercises

9
8.2.1 Necessary Conditions
  • A deadlock situation arise if the following four
    conditions hold simultaneously
  • Mutual exclusion
  • At least one resource must be held in a
    nonsharable mode
  • Hold and wait
  • Hold at least one resource and wait to acquire
    additional resources that are currently being
    held by other processes
  • No preemption
  • Resources cannot be preempted
  • Circular wait
  • P0 is waiting for a resource that is held by P1,
    P1 is waiting for a resource that is held by P2,
    , Pn1 is waiting for a resource that is held by
    Pn, and Pn is waiting for a resource that is held
    by P0.

10
8.2.2 Resource-Allocation Graph
  • System resource-allocation graph
  • A directed graph for describing deadlocks
  • A set of vertices V
  • Active processes
  • P P1, P2, , Pn
  • Resource types
  • R R1, R2, , Rn
  • A set of edges E
  • A request edge
  • Pi -gt Rj
  • An assignment edge
  • Rj -gt Pi
  • 4 instances

Pi
Rj
Pi
Rj
11
Resource Allocation Graph
  • Sets P, R, and E
  • P P1, P2, P3
  • R R1, R2, R3 , R4
  • E P1 -gtR1, P2 -gtR3, R1 -gtP2, R2
    -gtP2, R2 -gtP1, R3 -gtP3
  • Resource instances
  • R1 one instance
  • R2 two instances
  • R3 one instance
  • R4 three instances

12
Resource Allocation Graph
  • If the graph contains no cycles
  • No process in the system is deadlocked
  • If the graph does contain a cycle
  • A deadlock may exist

13
Resource Allocation Graph
  • P3 requests an instance of R2
  • Two minimal cycles exist
  • P1 -gt R1 -gt P2 -gt R3 -gt P3 -gt R2 -gt P1
  • P2 -gt R3 -gt P3 -gt R2 -gt P2
  • Processes P1, P2, and P3 are deadlocked

14
Resource Allocation Graph
  • A cycle exists
  • P1 -gt R1 -gt P3 -gt R2 -gt P1
  • No deadlock
  • P4 may release its instance of R2
  • That resource can the be allocated to P3,
    breaking the cycle

15
Deadlock Characterization
  • In summary, if a resource-allocation graph
  • Does not have a cycle
  • The system is not in a deadlock state
  • Have a cycle
  • The system may or may not be in a deadlock state

16
Chapter 8 Deadlocks
  1. System Model
  2. Deadlock Characterization
  3. Methods for Handling Deadlocks
  4. Deadlock Prevention
  1. Deadlock Avoidance
  2. Deadlock Detection
  3. Recovery from Deadlock
  4. Summary
  5. Exercises

17
8.3 Methods for Handling Deadlocks
  • Deal with the deadlock problem in one of three
    ways
  • Use a protocol to prevent or avoid deadlocks,
    ensuring that the system will never enter a
    deadlock state
  • Allow the system to enter a deadlock state,
    detect it, and recover.
  • Ignore the problem altogether, and pretend that
    deadlocks never occur in the system
  • Deadlocks occurs infrequently (say, once per year)

18
Chapter 8 Deadlocks
  1. System Model
  2. Deadlock Characterization
  3. Methods for Handling Deadlocks
  4. Deadlock Prevention
  1. Deadlock Avoidance
  2. Deadlock Detection
  3. Recovery from Deadlock
  4. Summary
  5. Exercises

19
8.4 Deadlock Prevention
  • Ensure at least one of the four necessary
    conditions cannot hold
  • Mutual Exclusion
  • Hold and Wait
  • No Preemption
  • Circular Wait

20
Deadlock Prevention
  • Mutual Exclusion
  • Must hold for nonsharable resources ( ex. a
    printer)
  • We cannot prevent deadlocks by denying the
    mutual-exclusion condition
  • Some resources are intrinsically nonsharable
  • Hold and Wait
  • Whenever a process requests a resource, it does
    not hold any other resources
  • Request and be allocated all resources before
    execution
  • Request resources only when the process has none
  • Main disadvantages
  • Low resource utilization
  • Starvation is possible

21
Deadlock Prevention
  • No Preemption
  • If a process that is holding some resources
    requests another resource that cannot be
    immediately allocated to it, then all resources
    currently being held are released.
  • Preempted resources are added to the list of
    resources for which the process is waiting.
  • Process will be restarted only when it can regain
    its old resources, as well as the new ones that
    it is requesting.
  • Applied to resources whose state can be easily
    saved and restored
  • Such as CPU registers and memory spaces
  • No applied to printers and tape drives

22
Deadlock Prevention
  • Circular Wait
  • Impose a total ordering of all resource types
  • A one-to-one function F R -gt N
  • N is the set of natural numbers
  • require that each process requests resources in
    an increasing order of enumeration
  • Initially request any number of instances of a
    resource type Ri
  • Request instances of resource type Rj if and only
    if F(Rj)gtF(Ri)
  • Example
  • F(tape drive) 1
  • F(disk drive) 5
  • F(printer) 12

23
Chapter 8 Deadlocks
  1. System Model
  2. Deadlock Characterization
  3. Methods for Handling Deadlocks
  4. Deadlock Prevention
  1. Deadlock Avoidance
  2. Deadlock Detection
  3. Recovery from Deadlock
  4. Summary
  5. Exercises

24
8.5 Deadlock Avoidance
  • Possible side effects of preventing deadlocks
  • Low device utilization
  • Reduced system throughput
  • Avoid deadlock
  • Require additional information about how
    resources are to be requested
  • Simplest and most useful model
  • Each process declare the maximum number of
    resources of each type that it may need
  • Possible to ensure that the system will never
    enter a deadlock state

25
8.5.1 Safe State
  • If the system can allocate resources to each
    process in some order and still avoid a deadlock
  • A safe sequence ltP1, P2, , Pngt
  • for each Pi , the resources that Pi can still
    request can be satisfied by currently available
    resources resources held by all the Pj , with j
    lt i.
  • If Pi resource needs are not immediately
    available, then Pi can wait until all Pj have
    finished.
  • When Pj is finished, Pi can obtain needed
    resources, execute, return allocated resources,
    and terminate.
  • When Pi terminates, Pi1 can obtain its needed
    resources, and so on.
  • Unsafe no such sequence exists

26
Basic Facts
  • If a system is in safe state
  • no deadlocks
  • If a system is in unsafe state
  • possibility of deadlock.
  • Avoidance
  • ensure that a system will never enter an unsafe
    state.

27
An Example
  • A system with 12 magnetic tape drives and 3
    processes P0, P1, and P2
  • The sequence ltP1, P0, P2gt satisfies the safety
    condition.

Maximum Needs Current Needs
P0 10 5
P1 4 2
P2 9 2
28
An Example
  • Process P2 requests and is allocated 1 more tape
    drive
  • The system is no longer in a safe state.
  • If a process requests a resource that is
    currently available, it may still have to wait.

Maximum Needs Current Needs
P0 10 5
P1 4 2
P2 9 3
29
8.5.2 Resource-Allocation Graph Algorithm
  • Resource-allocation graph with only one instance
    of each resource type
  • Used for deadlock avoidance
  • Claim edge Pi -gt Rj (represented by a dashed
    line)
  • Process Pj may request resource Rj
  • Converts to request edge when a process requests
    a resource.
  • When a resource is released by a process,
    assignment edge reconverts to a claim edge.
  • Resources must be claimed a priori in the system.

30
Resource-Allocation GraphFor Deadlock Avoidance
31
Unsafe State InResource-Allocation Graph
32
8.5.3 Bankers Algorithm
  • Multiple instances
  • resource-allocation graph allocation is not
    applicable
  • A new process must declare the maximum number of
    instances of each resource type that it may need.
  • Cannot exceed the total number of resources in
    the system
  • Determine whether the allocation of these
    resources will leave the system in a safe state
  • If yes, the resources are allocated
  • If not, the process must wait until some other
    process releases enough resources

33
Data Structuresfor the Bankers Algorithm
  • Let n number of processes, and m number of
    resources types.
  • Available Vector of length m. If Available j
    k, there are k instances of resource type Rj
    available.
  • Max n x m matrix. If Max i, j k, then
    process Pi may request at most k instances of
    resource type Rj.
  • Allocation n x m matrix. If Allocation i, j
    k then Pi is currently allocated k instances of
    Rj.
  • Need n x m matrix. If Need i, j k, then Pi
    may need k more instances of Rj to complete its
    task.
  • Need i, j Max i, j Allocation i, j .

34
Notationfor the Bankers Algorithm
  • Let X and Y be vectors of length n.
  • X Y if and only if X i Y i for all i
    1,2, , n
  • For example
  • if X (1, 7, 3, 2) and Y (0, 3, 2, 1),then Y
    X

35
8.5.3.1 Safety Algorithm
  • Find out whether or not the system is in a safe
    state
  • Let Work and Finish be vectors of length m and n,
    respectively. Initialize
  • Work Available
  • Finish i false for i 1, 2, 3, , n.
  • Find an i such that both
  • Finish i false
  • Needi ? Work.
  • If no such i exists, go to step 4.
  • Work Work AllocationiFinish i truego
    to step 2.
  • If Finish i true for all i, then the system
    is in a safe state.

36
8.5.3.2 Resource-Request Algorithm
  • Requesti j k
  • Process Pi wants k instances of resource type Rj.
  • If Requesti Needi, go to step 2. Otherwise,
    raise an error condition, since the process has
    exceeded its maximum claim.
  • If Requesti Available, go to step 3. Otherwise
    Pi must wait, since the resources are not
    available.
  • Pretend to allocate requested resources to Pi by
    modifying the state as follows
  • Available Available Requesti
  • Allocationi Allocationi Requesti
  • Needi Needi Requesti
  • If safe -gt the resources are allocated to Pi .
  • If unsafe -gt Pi must wait, and the old
    resource-allocation state is restored.

37
8.5.3.3 An Illustrative Example
  • Three resource types
  • A 10 instances
  • B 5 instances
  • C 7 instances
  • Five processes
  • P0 through P4
  • Snapshot at time T0
  • Allocation M a x Available Need
  • A B C A B C A B C A B C
  • P0 0 1 0 7 5 3 3 3 2 7 4 3
  • P1 2 0 0 3 2 2 1 2 2
  • P2 3 0 2 9 0 2 6 0 0
  • P3 2 1 1 2 2 2 0 1 1
  • P4 0 0 2 4 3 3 4 3 1
  • ltP1, P3, P4, P2, P0gt satisfies the safety
    criteria.

38
8.5.3.3 An Illustrative Example
  • P1 requests
  • One instance of resource type A
  • Two instances of resource type C
  • Request1 (1, 0, 2) Available (3, 3, 2)
  • Snapshot at time T0
  • Allocation Need Available
  • A B C A B C A B C
  • P0 0 1 0 7 4 3 2 3 0
  • P1 3 0 2 0 2 0
  • P2 3 0 2 6 0 0
  • P3 2 1 1 0 1 1
  • P4 0 0 2 4 3 1
  • ltP1, P3, P4, P0, P2gt satisfies the safety
    criteria.
  • Grant the request of process P1.

39
Chapter 8 Deadlocks
  1. System Model
  2. Deadlock Characterization
  3. Methods for Handling Deadlocks
  4. Deadlock Prevention
  1. Deadlock Avoidance
  2. Deadlock Detection
  3. Recovery from Deadlock
  4. Summary
  5. Exercises

40
8.6 Deadlock Detection
  • Allow the system to enter deadlock state
  • An algorithm that examines the state of the
    system to determine whether a deadlock has
    occurred
  • An algorithm to recover from the deadlock
  • A detection-and-recovery scheme requires overhead
  • Run-time costs
  • Potential losses

41
8.6.1 Single Instance ofEach Resource Type
  • A wait-for graph obtained from
    resource-allocation graph
  • Remove the nodes of type resource
  • Collapse the appropriate edges

42
8.6.1 Single Instance ofEach Resource Type
  • A deadlock exists in the system if and only if
    the wait-for graph contains a cycle.
  • To detect deadlocks
  • Maintain the wait-for graph
  • Periodically invoke an algorithm that searches
    for a cycle in the graph

43
8.6.2 Several Instances ofa Resource Type
  • The algorithm employs several time-varying data
    structures
  • Available
  • A vector of length m indicates the number of
    available resources of each type.
  • Allocation
  • An n x m matrix defines the number of resources
    of each type currently allocated to each process.
  • Request
  • An n x m matrix indicates the current request of
    each process. If Request i, j k, then process
    Pi is requesting k more instances of resource
    type Rj.

44
Detection Algorithm
  • 1. Let Work and Finish be vectors of length m and
    n, respectively. Initialize
  • (a) Work Available
  • (b) For i 1,2, , n, if Allocationi ? 0, then
    Finishi falseotherwise, Finishi true.
  • 2. Find an index i such that both
  • (a) Finishi false
  • (b) Requesti ? Work
  • If no such i exists, go to step 4.

45
Detection Algorithm (Cont.)
  • 3. Work Work AllocationiFinishi truego
    to step 2.
  • 4. If Finishi false, for some i, 1 ? i ? n,
    then the system is in deadlock state. Moreover,
    if Finishi false, then Pi is deadlocked.

Algorithm requires an order of O(m x n2)
operations to detect whether the system is in
deadlocked state.
46
Example of Detection Algorithm
  • Five processes P0 through P4 three resource
    types A (7 instances), B (2 instances), and C (6
    instances).
  • Snapshot at time T0
  • Allocation Request Available
  • A B C A B C A B C
  • P0 0 1 0 0 0 0 0 0 0
  • P1 2 0 0 2 0 2
  • P2 3 0 3 0 0 0
  • P3 2 1 1 1 0 0
  • P4 0 0 2 0 0 2
  • Sequence ltP0, P2, P3, P1, P4gt will result in
    Finishi true for all i.

47
Example (Cont.)
  • P2 requests an additional instance of type C.
  • Request
  • A B C
  • P0 0 0 0
  • P1 2 0 1
  • P2 0 0 1
  • P3 1 0 0
  • P4 0 0 2
  • State of system?
  • Can reclaim resources held by process P0, but
    insufficient resources to fulfill other
    processes requests.
  • Deadlock exists, consisting of processes P1, P2,
    P3, and P4.

48
8.6.3 Detection-Algorithm Usage
  • When, and how often, to invoke depends on
  • How often a deadlock is likely to occur?
  • How many processes will need to be rolled back?
  • one for each disjoint cycle
  • The detection algorithm can be invoked
  • When a request cannot be granted immediately
  • Identify the specific process that caused the
    deadlock
  • At arbitrary points in time
  • Not be able to tell which of the many deadlocked
    processes caused the deadlock

49
Chapter 8 Deadlocks
  1. System Model
  2. Deadlock Characterization
  3. Methods for Handling Deadlocks
  4. Deadlock Prevention
  1. Deadlock Avoidance
  2. Deadlock Detection
  3. Recovery from Deadlock
  4. Summary
  5. Exercises

50
8.7.1 Process Termination
  • Abort all deadlocked processes.
  • Abort one process at a time until the deadlock
    cycle is eliminated.
  • In which order should we choose to abort?
  • Priority of the process.
  • How long process has computed, and how much
    longer to completion.
  • Resources the process has used.
  • Resources process needs to complete.
  • How many processes will need to be terminated.
  • Is process interactive or batch?

51
8.7.2 Resource Preemption
  • Three issues
  • Selecting a victim
  • To minimize cost
  • Number of resources
  • Amount of time
  • Rollback
  • Return to some safe state, restart process for
    that state
  • The simplest solution is a total rollback
  • Starvation
  • Same process may always be picked as victim,
    include number of rollback in cost factor
  • Include the number of rollbacks in the cost factor

52
Chapter 8 Deadlocks
  1. System Model
  2. Deadlock Characterization
  3. Methods for Handling Deadlocks
  4. Deadlock Prevention
  1. Deadlock Avoidance
  2. Deadlock Detection
  3. Recovery from Deadlock
  4. Summary
  5. Exercises

53
Summary
  • P.266

54
Chapter 8 Deadlocks
  1. System Model
  2. Deadlock Characterization
  3. Methods for Handling Deadlocks
  4. Deadlock Prevention
  1. Deadlock Avoidance
  2. Deadlock Detection
  3. Recovery from Deadlock
  4. Summary
  5. Exercises

55
Exercises
  • 8.2
  • 8.4
  • 8.5
  • 8.12
  • 8.13

56
The End
Write a Comment
User Comments (0)
About PowerShow.com