1 / 88

Understanding Operating Systems Sixth Edition

Understanding Operating Systems Sixth Edition. Chapter 5 Process Management. Learning Objectives. After completing this chapter, you should be able to describe: Several causes of system deadlock and livelock The difference between preventing and avoiding deadlocks

vanya
Télécharger la présentation

Understanding Operating Systems Sixth Edition

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Understanding Operating SystemsSixth Edition Chapter 5Process Management

  2. Learning Objectives After completing this chapter, you should be able to describe: • Several causes of system deadlock and livelock • The difference between preventing and avoiding deadlocks • How to detect and recover from deadlocks Understanding Operating Systems, Sixth Edition

  3. Learning Objectives (cont’d.) • The concept of process starvation and how to detect and recover from it • The concept of a race and how to prevent it • The difference between deadlock, starvation, and race Understanding Operating Systems, Sixth Edition

  4. Deadlock • In early OS, deadlock was known by the more descriptive phrase - “deadly embrace”. • Happens when the system freezes. • A system-wide tangle of resource requests that begins when two or more jobs are put on HOLD, each waiting for a vital resource to become available. • The problem builds when the resources needed by those jobs are the resources held by other jobs that are also waiting to run but cannot because they’re waiting for other unavailable resources. • The tangled jobs come to a standstill. Understanding Operating Systems, Sixth Edition

  5. Deadlock (cont’d) • The deadlock is complete if the remainder of the system comes to a standstill as well. • When the situation can’t be resolved by the OS, intervention is required. • Deadlock affects more than one job. • Because resources are being tied up, the entire system, not just a few programs, is affected. • Deadlocks became prevalent with the introduction of interactive systems, which generally improve the use of resources through dynamic resource sharing, but this capability also increases the possibility of deadlocks. Understanding Operating Systems, Sixth Edition

  6. Deadlock (cont'd.) Understanding Operating Systems, Sixth Edition

  7. Deadlock (cont'd.) • In some computer systems, deadlocks are regarded as a mere inconvenience that causes delays. • But for real-time systems, deadlocks cause critical situations. • Regardless of the environment, the OS must either prevent deadlocks or resolve them when they happen. Understanding Operating Systems, Sixth Edition

  8. Seven Cases of Deadlock • A deadlock usually occurs when nonshareable, nonpreemptable resources, such as files, printers or scanners are allocated to jobs that eventually require other nonshareable nonpreemptive, resources that have been locked by other jobs. • Deadlocks can also occur on shareable resources that are locked, such as disks and databases. Understanding Operating Systems, Sixth Edition

  9. Case 1: Deadlocks on File Requests • If jobs are allowed to request and hold files for the duration of their execution, a deadlock can occur. • Example (Figure 5.2) • Two programs (P1, P2) and two files (F1, F2) • Deadlock sequence • P1 has access to F1 and also requires F2 • P2 has access to F2 and also requires F1 • Deadlock remains • Until one program withdrawn or • Until one program forcibly removed and file released • Other programs requiring F1 or F2 • Put on hold for duration of situation Understanding Operating Systems, Sixth Edition

  10. Case 1: Deadlocks on File Requests (cont'd.) Understanding Operating Systems, Sixth Edition

  11. Case 2: Deadlocks in Databases • A deadlock can occur if two processesaccess and lock records in a database. • Database queries and transactions are often relatively brief processes that either search or modify parts of a database. • Requests usually arrive at random and may be interleaved arbitrarily. • Locking is a technique used to guarantee the integrity of the data through which the user locks out all other users while working with the database. Understanding Operating Systems, Sixth Edition

  12. Case 2: Deadlocks in Databases (cont’d) • Locking can be done at three different levels: • The entire database can be locked for the duration of the request; • The most extreme and most successful solution. • Prevents a deadlock from occurring but it restricts access to the database to one user at a time. • In a multiuser environment, response times are significantly slowed. • Normally an unacceptable solution. Understanding Operating Systems, Sixth Edition

  13. Case 2: Deadlocks in Databases (cont’d) • A subsection of the database can be locked: • When the locking is performed on only one part of the database, access time is improved but the possibility of a deadlock is increased because different processes sometimes need to work with several parts of the data base at the same time. • The individual record can be locked until the request is completed. • Same as above. Understanding Operating Systems, Sixth Edition

  14. Case 2: Deadlocks in Databases (cont'd.) • Example: two processes (P1 and P2) • Each needs to update two records (R1 and R2) • Deadlock sequence • P1 accesses R1 and locks it • P2 accesses R2 and locks it • P1 requests R2 but locked by P2 • P2 requests R1 but locked by P1 • Race between processes: • An alternative is to avoid the use of locks • If locks are not used to preserve the integrity of the database, the updated records might only include some of the data, and their contents would depend on the order in which each process finishes its execution. Understanding Operating Systems, Sixth Edition

  15. Case 2: Deadlocks in Databases (cont'd.) Understanding Operating Systems, Sixth Edition

  16. Case 3: Deadlocks in Dedicated Device Allocation • The use of a group of dedicated devices can also deadlock the system. • Example • Twoprograms (P1, P2) • Need two tape drives each • Only two tape drives in system • Deadlock sequence • P1 requests tape drive 1 and gets it • P2 requests tape drive 2 and gets it • P1 requests tape drive 2 but blocked • P2 requests tape drive 1 but blocked Understanding Operating Systems, Sixth Edition

  17. Case 4: Deadlocks in Multiple Device Allocation • Deadlocks can happen when several processes request, and hold on to, several dedicated devices. • Example (Figure 5.4) • Three programs (P1, P2, P3) • Three dedicated devices (tape drive, printer, plotter) • Deadlock sequence • P1 requests and gets tape drive • P2 requests and gets printer • P3 requests and gets the plotter • P1 requests printer but blocked • P2 requests plotter but blocked • P3 requests tape drive but blocked Understanding Operating Systems, Sixth Edition

  18. Case 4: Deadlocks in Multiple Device Allocation (cont'd.) Understanding Operating Systems, Sixth Edition

  19. Case 5: Deadlocks in Spooling • Printers are usually sharable devices (Virtual devices) that use high-speed storage to transfer data between it and the CPU. • The spooler accepts output from several users and acts as a temporary storage area for all output until the printer is ready to accept it (spooling). • If the printer needs all of a job’s output before it will begin printing, but the spooling system fills the available space with only partially completed output, a deadlock can occur. Understanding Operating Systems, Sixth Edition

  20. Case 5: Deadlocks in Spooling (cont'd.) • Deadlock Sequence: • Printer needs all job output before printing begins • Spooling system fills disk space area • No one job has entire print output in spool area • Results in partially completed output for all jobs • Results in deadlock • Any part of the system that relies on spooling, such as one that handles incoming jobs or transfers files over a network, is vulnerable to such a deadlock. Understanding Operating Systems, Sixth Edition

  21. Case 6: Deadlocks in a Network • A network that’s congested or has filled a large percentage of its I/O buffer space can become deadlocked if it doesn’t have protocols to control the flow of messages through the network. • Example (Figure 5.5) • Seven computers on network • Each on different nodes • Direction of arrows • Indicates message flow • Deadlock sequence • All available buffer space fills Understanding Operating Systems, Sixth Edition

  22. Case 6: Deadlocks in a Network (cont'd.) Understanding Operating Systems, Sixth Edition

  23. Case 7: Deadlocks in Disk Sharing • Disks are designed to be shared. • It’s not uncommon for two processes to be accessing different areas of the same disk. • This ability to share creates an active type of deadlock, known as livelock. • Processes use a form of busy-waiting that’s different from a natural wait. • It’s waiting to share a resource but never actually gains control of it. Understanding Operating Systems, Sixth Edition

  24. Case 7: Deadlocks in Disk Sharing (cont’d) • Example (Figure 5.6) • Two competing processes are sending conflicting commands, causing livelock. • Neither process is blocked, which would create a deadlock. • Each is active but never reaches fulfillment. • Each process waiting for I/O request • One at cylinder 20 andone at cylinder 310 • Deadlock sequence • Neither I/O request satisfied • Device putsrequest on holdwhile attempting to fulfill other request. Understanding Operating Systems, Sixth Edition

  25. Case 7: Deadlocks in Disk Sharing (cont’d) • Example (Figure 5.6) • P1 issues a command to access track 20 of a disk. • While the control unit is moving the arm to track 20 • P1 is put on hold • The I/O channel is free to process the next I/O request. • While the arm is moving into position, P2 gains control of the I/O channel and issues a command to access track 310. • If the command is not “locked out”, P2 will be put on hold while the control unit moves the arm to track 310. Understanding Operating Systems, Sixth Edition

  26. Case 7: Deadlocks in Disk Sharing (cont’d) • Example (Figure 5.6) • Because P2 is “on hold” while the arm is moving, the channel can be captures again by P1, which reconfirms its command to “read from track 10”. • Because the last command from P2 had forced the arm mechanism to track 310, the disk control unit begins to reposition the arm to track 20 to satisfy P1. • The I/O channel would be released because P1 is once again put on hold, so it could be captured by P2, which rediscovers that the arm mechanism needs to be repositioned. Understanding Operating Systems, Sixth Edition

  27. Case 7: Deadlocks in Disk Sharing (cont’d) • Example (Figure 5.6) • As a result, the arm is in a constant state of motion, moving back and forth between tracks 20 and 310 as it responds to the two competing commands, but satisfies neither. Understanding Operating Systems, Sixth Edition

  28. Case 7: Deadlocks in Disk Sharing (cont'd.) Understanding Operating Systems, Sixth Edition

  29. Conditions for Deadlock • In each of these seven cases, the deadlock (or livelock) involved several processes and resources. • Each deadlock was preceded by the simultaneous occurrence of four conditions that the OS (or other systems) could have recognized: • Mutual exclusion • Resource holding • No preemption • Circular wait • Each of these four conditions is necessary for the OS to work smoothly. Understanding Operating Systems, Sixth Edition

  30. Conditions for Deadlock (cont’d) • None of them can be removed easily without causing the system’s overall functioning to suffer. • The system needs to recognize the combination of conditions before they occur and threaten to cause the system to lock up. Understanding Operating Systems, Sixth Edition

  31. Conditions for Deadlock (cont'd.) • Mutual exclusion • Allowing only one process access to a dedicated resource. • The first condition for deadlock. • Resource holding • Holding resource and not releasing it • Waiting for other job to retreat • The second condition for deadlock. • No preemption • Lack of temporary reallocation of resources. • The third condition for deadlock. Understanding Operating Systems, Sixth Edition

  32. Conditions for Deadlock (cont'd.) • Circular wait • Each process involved in the impasse is waiting for another to voluntarily release the resource so that at least one will be able to continue on and eventually arrive at the destination. • Fourth condition for deadlock. • All four conditions are required for the deadlock to occur. • Deadlock remains until one condition removed Understanding Operating Systems, Sixth Edition

  33. Modeling Deadlocks • Directed graphs • Circles represent processes • Squares represent resources • Solid arrow from resource to process • Processholding resource • Solid arrow from a process to resource • Processwaiting for resource • Arrow direction indicates flow • Cycle in graph • Deadlockinvolving processes and resources Understanding Operating Systems, Sixth Edition

  34. Modeling Deadlocks (cont'd.) Understanding Operating Systems, Sixth Edition

  35. Modeling Deadlocks (cont'd.) • Three graph scenarios to help detect deadlocks • System has three processes (P1, P2, P3) • System has three resources (R1, R2, R3) • Scenario one: no deadlock • Resources released before next process request • Scenario two: deadlock • Processes waiting for resource held by another • Scenario three: no deadlock • Resources released before deadlock Understanding Operating Systems, Sixth Edition

  36. Modeling Deadlocks (cont'd.) • No deadlock • Resources released before next process request Understanding Operating Systems, Sixth Edition

  37. Modeling Deadlocks (cont'd.) Understanding Operating Systems, Sixth Edition

  38. Modeling Deadlocks (cont'd.) • Deadlock • Processes waiting for resource held by another Understanding Operating Systems, Sixth Edition

  39. Modeling Deadlocks (cont'd.) Understanding Operating Systems, Sixth Edition

  40. Modeling Deadlocks (cont'd.) • No deadlock • Resources released before deadlock Understanding Operating Systems, Sixth Edition

  41. Modeling Deadlocks (cont'd.) Understanding Operating Systems, Sixth Edition

  42. Modeling Deadlocks (cont'd.) • Another example • Resources of same type • Allocated individually or grouped in same process • Graph clusters devices into one entity • Allocated individually or grouped in different process • Graph clusters devices into one entity Understanding Operating Systems, Sixth Edition

  43. Modeling Deadlocks (cont'd.) Understanding Operating Systems, Sixth Edition

  44. Strategies for Handling Deadlocks • The requests and releases are received in an unpredictable order, which makes it very difficult to design a foolproof preventive policy. • OSs use one of three strategies to deal with deadlocks: • Prevent one of the four conditions from occurring. • Avoid the deadlock if it becomes probable. • Detect the deadlock when it occurs and recover from it gracefully. Understanding Operating Systems, Sixth Edition

  45. Strategies for Handling Deadlocks (cont'd.) • Prevention: • To prevent deadlocks, the OS must eliminate one of the four necessary conditions: • Complicated by the fact that the same condition can’t be eliminated from every resource. • Mutual exclusion: • Necessary in any computer system because some resources, such as memory, CPU, and dedicated devices must be exclusively allocated to one user at a time. • In the case of I/O devices (printers, the mutual exclusion may be bypassed by spooling. Understanding Operating Systems, Sixth Edition

  46. Strategies for Handling Deadlocks (cont'd.) • Prevention: • Resource Holding: • A job holds on to one resource while waiting for another one that’s not yet available. • Could be sidestepped by forcing each job to request, at creation time, every resource it will need to run to completion. • If every job in a batch system is given as much memory as it needs, then the number of active jobs will be dictated by how many can fit in memory. • Would significantly decrease the degree of multiprogramming. • Peripheral devices would be idle because they would be allocated to a job even though they wouldn’t be use all the time. Understanding Operating Systems, Sixth Edition

  47. Strategies for Handling Deadlocks (cont'd.) • Prevention: • Resource Holding: • Used successfully in batch environments although it: • Reduced the effective use of resources; • Restricted the amount of multiprogramming. • Doesn’t work well in interactive systems. Understanding Operating Systems, Sixth Edition

  48. Strategies for Handling Deadlocks (cont'd.) • Prevention (cont'd.) • No preemption: • Could be bypassed by allowing the OS todeallocate resources from jobs. • Can be done if the state of the job can be easily saved and restored. • As when a job is preempted in a round robin environment or a page is swapped to secondary storage in a virtual memory system. • Preemption of a dedicated I/O device, during the modification process, however, can require some extremely unpleasant recovery tasks. Not accepted to preempt dedicated I/O device or files during modification. Understanding Operating Systems, Sixth Edition

  49. Strategies for Handling Deadlocks (cont'd.) • Prevention (cont'd.) • Circular Wait: • Hierarchical Ordering: • Based on a numbering system for the resources: • Printer = 1; • Disk = 2; • Tape = 3; • Plotter = 4; • And so on. Understanding Operating Systems, Sixth Edition

  50. Strategies for Handling Deadlocks (cont'd.) • Prevention (cont'd.) • The system forces each job to request its resources in ascending order. • If a job needed a printer and then a plotter, it would request them in that order. • Printer (#1) • Plotter (#4) • If the job required the plotter first and then a plotter, it would still request the printer first even though it wouldn’t be used right away. • A job could request a printer (#1) and then a disk (#2) and then a tape (#3); but if it needed another printer (#1) late in its processing, it would still have to anticipate that need when it requested the first one, and before it requested the disk. Understanding Operating Systems, Sixth Edition

More Related