Sunteți pe pagina 1din 14

-------------------------------------------------------------------------------ANSWERS TO PROBLEMS FROM CHAPTERS 8-14 -------------------------------------------------------------------------------8.2 Is it possible to have a deadlock involving only one process?

Explain your answer. Answer: Recall that there are four necessary conditions for deadlock. Number 4 is circular-wait. Deadlock with one process is not possible, because it is not possible to have circular wait with only one process, thus failing a necessary condition. There is no second process to form a circle with the first one. For the same reason, it is not possible to have a deadlock involving only one resource. This follows directly from the hold-and-wait condition. -------------------------------------------------------------------------------8.3 Consider the traffic deadlock depicted in the Figure 8.8. A. Show that the four necessary conditions for deadlock indeed hold in this example. B. State a simple rule that will avoid deadlocks in this system. Answer: A. The four necessary conditions for deadlock hold in this example for the following reasons (i) Mutual Exclusion : Each of the vehicles present in the streets hold a non-sharable resource: the part of the road they occupy, which they cannot share with the other vehicles. (ii) Hold and Wait : Each of the vehicles hold the space resource they occupy and are waiting the space in front of them to be freed by other waiting vehicles. (iii) No Preemption : There is no possibility of preemption as none of the vehicles can give up their resource. In this situation preemption would have to take the form of a vehicle pulling into a parking lot, or a crane reaching down and lifting a vehicle off the road. (iv) Circular Wait : Circular wait is present because each vehicle is waiting for the space in front of it, and some vehicles occupy spaces where two vehicles wait on them. It is thus possible to trace a cycle of waiting cars. This is the weakest assertion in the set, though, and is clearly untrue out at the edges somewhere, since some car can clearly move someplace in the city.If you have ever experienced grid-lock, though you know that this is small comfort, and tht a rule to avoid even "local" deadlock is extremely desirable. B. The simple rule that could be used to avoid traffic deadlocks in such a system is that intersections should always remain clear as lights change. In this way, the resource of space in the intersection is freed for use at periodic intervals (light changes). -------------------------------------------------------------------------------8.10 Consider a computer system that runs 5,000 jobs per month with no deadlock prevention or deadlock avoidance scheme. Deadlocks occur about twice per month, and the operator must terminate and rerun about 10 jobs per deadlock. Each job is worth about $2 (in CPU time) , and the jobs terminated tend to be about half done when they are aborted. A systems programmer has estimated that a deadlock avoidance algorithm(like the Banker's algorithm ) could be installed in the system with an increase in the average execution time per job of about 10 percent. Since the machine currently has 30-percent idle time, all 5000 jobs per month could still be run, although turnaround time would increase by about 20 percent on an average. A. What are the arguments for installing the deadlock-avoidance algorithm? B. What are the arguments against installing the deadlock-avoidance algorithm? Answer: A. The arguments in favour of installing the deadlock-avoidance

algorithm are : Avoids deadlocks and the costs of reruns. Avoids waste of resources as the reruns require duplicate use of resources and time to run the aborted processes all over again Increases useful utilization of the resources as the system s idle-time is reduced. B. The arguments against installing the deadlock avoidance algorithm are : Increases total execution time for processes. Increases the total cost as the total execution time of processes increases by 10%. The processes take more time to complete due to an increase in the turnaround time by 20 %. It introduces an overhead on the execution of every processDeciding between the arguments in favor and against deadlock control requires an examination of the costs involved. In other words, it depends on the details of the situation.The problem states that the computing load represents about $10K per month in computing time, and that about 20 jobs having used $1 each in CPU time are terminated per month (this information is easily derived fromt he facts stated in the problem). That means that not controlling deadlock costs about $20 per month. The problem also states that controlling deadlock introduces overhad costing about 10% on every job, or about $500. The proposal to control deadlock thus proposes to spend about $500 (overhead) to save about $20 (deadlock loss). -------------------------------------------------------------------------------9.1 Name two differences between logical and physical addresses. Answer: Logical address is an address seen by the CPU while a physical address is seen by the memory. A physical address is limited to the amount of installed memory while a logical address is limited by the address size of the processor. -------------------------------------------------------------------------------9.2 Explain the difference between internal and external fragmentation. Answer: Internal Fragmentation is the area in a region or a page that is not used by the job occupying that region or page. This space is unavailable for use by the system until that job is finished and the page or region is released. External fragmentation is the area or region that is not used because it is free. -------------------------------------------------------------------------------9.3 Descibe the following allocation algorithms: (A) First-fit: search the list of available memory and allocate the first block that is big enough. (B) Best-fit: search the entire list of available memory and allocate the smallest block that is big enough. (C) Worst-fit: search the entire list of available memory and allocate the largest block. -------------------------------------------------------------------------------9.5 Given memory partitions of 100K, 500K, 200K, 300K, and 600K (in order), how would each of the First-fit, Best-fit, and Worst-fit algorithms place processes of 212K, 417K, 112K, and 426K (in order)? Which algorithm makes the most efficient use of memory? Answer: a. First-fit: 212K is put in 417K is put in 112K is put in 426K must wait b. Best-fit: 212K is put in 417K is put in 112K is put in 426K is put in c. Worst-fit:

500K partition 600K partition 288K partition (new partition 288K = 500K - 212K) 300K 500K 200K 600K partition partition partition partition

212K is put in 600K partition 417K is put in 500K partition 112K is put in 388K partition 426K must wait In this example, Best-fit turns out to be the best. -------------------------------------------------------------------------------9.8 Consider a logical address space of eight pages of 1024 words each, mapped onto a physical memory of 32 frames. A. How many bits are there in the logical address? B. How many bits are there in the physical address? Answer: A. Logical address: 13 bits B. Physical address: 15 bits -------------------------------------------------------------------------------9.16 Consider the following segment table: Segment Base Length 0 219 600 1 2300 14 2 90 100 3 1327 580 4 1952 96 What are the physical addresses for the following logical addresses? a. 0,430 b. 1,10 c. 2,500 d. 3,400 e. 4,112 Answer: A. 219 + 430 = 649 B. 2300 + 10 = 2310 C. illegal reference, trap to operating system D. 1327 + 400 = 1727 E. illegal reference, trap to operating system -------------------------------------------------------------------------------10.2 Assume that you have a page-reference string for a process with m frames (initially all empty). The page-reference string has length p; n distinct page numbers occur in it. Answer these questions for any page-replacement algorithms: A. What is a lower bound on the number of page faults? B. What is an upper bound on the number of page faults? Answer: A. N, because a distinct page numbers always generates a page fault, even if two difference pages refer to the same physical page frame. B. P, if we reference pages P times, we will generate at most P page faults. -------------------------------------------------------------------------------Problem 10.2: Assume that you have a page-reference string for a process with m frames (initially all empty). The page-reference string has length p; n distinct page numbers occur in it. Answer these questions for any page replacement algorithm: A. What is a lower bound on the number of page faults? B. What is an upper bound on the number of page faults? Answer: A. Lower Bound: n. The reference string indicates that the program actually references n distinct pages, and the best that any page replacement algorithm can do is make the first page fault for a page the last. B. Upper Bound: p. The worst possible situation is one where the working set is so small, and the page replacement algorithm so stupid, that every reference

to a new page in the reference string is a page fault. -------------------------------------------------------------------------------10.4 Which of the following programming techniques and structures are "good" for a demandpaged environment ? Which are "not good"? Explain your answers. a. Stack b. Hashed symbol table c. Sequential search d. Binary search e. Pure code f. Vector operations g. Indirection Answer: a. Stack--good. b. Hashed symbol table--not good. c. Sequential search--good. d. Binary search--not good. e. Pure code--good. f. Vector operations--good. g. Indirection--not good. -------------------------------------------------------------------------------10.9 Consider a demand-paging system with the following time-measured utilizations: CPU utilization 20% Paging disk 97.7% Other I/O devices 5% -------------------------------------------------------------------------------11.5 What are the advantages and disadvantages of recording the name of the creating pro- gram with the file's attributes (as is done in the Macintosh Operating System)? Answer: By recording the name of the creating program, the operating system is able to implement features (such as automatic program invocation when the file is accessed) based on this information. It does add overhead in the operating system and require space in the file descriptor, however. -------------------------------------------------------------------------------11.5 What are the advantages and disadvantages of recording the name of the program that creates a file with the file's attributes (as is done in the Macintosh operating system)? Answer: Advantages: A file tagged with a program name indirectly points to the default program to open/execute the file. Firstly, this makes file dependency on application programs very explicit. This visibility is useful (more than that in having extensions in DOS and Windows) to the user in determining the type associated with the file. Furthermore, this is more risk-free in determining the program to open a file. A weird program cannot accidentally corrupt (unless forced by the user) the internal format of a file in trying to open it since here each file is named with the only program(s) that has/have access to it. Thus this makes the system more secure.Disadvantages: This strategy gives birth to long file names. Systems which deal with large number of files waste a considerable amount of space in storing the names of these files. Moreover, this reduces portability of the file. If a file is moved from one environment to another, then it would become useless if that particular program is unavailable to open it unless the file name is modified. A subtle error creeping inside the file-name may also render it completely paralyzed. Also, some files are used by multiple applications, so the one-to-one mapping with the embedded filename is much less useful in reality.

-------------------------------------------------------------------------------11.7 Explain the purpose of the open and close operations.Answer: The open operation informs the system that the named file is about to become active. The close operation informs the system that the named file is no longer in active use by the user who issued the close operation. -------------------------------------------------------------------------------11.9 Give an example of an application in which data in a file should be accessed in the following order: A. Sequentially: A movie player that plays a movie file sequentially. B. Randomly: A movie player that allows user to start playing movie at random locations of the file. -------------------------------------------------------------------------------11.13 Researchers have suggested that, instead of having an access list associated with each file(specifying which users can access the file, and how), we should have a user control listassociated with each user (specifying which files a user can access, and how). Discuss therelative merits of these two schemes. Answer: - File control list. Since the access control information is concentrated in one single place, it is easier to change access control information and this requires less space. - User control list. This requires less overhead when opening a file. -------------------------------------------------------------------------------12.2 Consider a system where free space is kept in a free-space list. A. Suppose that the pointer to the free-space list is lost. Can the system reconstruct the free-space list? Explain your answer. B. Suggest a scheme to ensure that the pointer is never lost as result of memory failure. Answer: A. In order to reconstruct the free list, it would be necessary to perform "garbage collection." This would entail searching the entire directory structure to determine which pages are already allocated to jobs. Those remaining unallocated pages could be relinked as the free-space list. B. The free-space list pointer could be stored on the disk, perhaps in several places. -------------------------------------------------------------------------------12.4 Why must the bit map for file allocation be kept on mass storage, rather than in main memory? Answer: In case of system crash (memory failure) the free-space list would not be lost as it would be if the bit map had been stored in main memory. -------------------------------------------------------------------------------12.5 Consider a system that supports the strategies of contiguous, linked, and indexed allo-cation. What criteria should be used in deciding which strategy is best utilized for a particular file? Answer: Contiguous -- if file is usually accessed sequentially, if file is relatively small. Linked -- if file is large and usually accessed sequentially. Indexed -- if file is large and usually accessed randomly. -------------------------------------------------------------------------------13.1 State three advantages of placing functionality in a device controller, rather than in the kernel. State three disadvantages.

Answer: Three advantages: Bugs are less likely to cause an operating system crash. Performance can be improved by utilizing dedicated hardware and hard-coded algo-rithms. The kernel is simplified by moving algorithms out of it. Three disadvantages: Bugs are harder to fix - a new firmware version or new hardware is needed. Improving algorithms likewise require a hardware updatei rather than just kernel or device driver update. Embedded algorithms could conflict with application's use of the device, causing de-creased performance. -------------------------------------------------------------------------------13.2 Consider the following I/O scenarios on a single-user PC. A. A mouse used with a graphical user interface B. A tape drive on a multitasking operating system (assume no device preallocation is available) C. A disk drive containing user files D. A graphics card with direct bus connection, accessible through memory-mapped I/O For each of these I/O scenarios, would you design the operating system to use buffering, spooling, caching, or a combination? Would you use polled I/O, or interrupt-driven I/O? Give reasons for your choices. Answer: A. A mouse used with a graphical user interface Buffering may be needed to record mouse movement during times when higher- priority operations are taking place. Spooling and caching are inappropriate. Inter- rupt driven I/O is most appropriate. B. A tape drive on a multitasking operating system (assume no device preallocation is available) Buffering may be needed to manage throughput difference between the tape drive and the source or destination of the I/O, Caching can be used to hold copies of data that resides on the tape, for faster access. Spooling could be used to stage data to the device when multiple users desire to read from or write to it. Interrupt driven I/O is likely to allow the best performance. C. A disk drive containing user files. Buffering can be used to hold data while in transit from user space to the disk, and visa versa. Caching can be used to hold disk-resident data for improved perfor- mance. Spooling is not necessary because disks are shared-access devices. Interrupt- driven I/O is best for devices such as disks that transfer data at slow rates. D. A graphics card with direct bus connection, accessible through memory-mapped I/O Buffering may be needed to control multiple access and for performance (double- buffering can be used to hold the next screen image while displaying the current one). Caching and spooling are not necessary due to the fast and shared-access natures of the device. Polling and interrupts are only useful for input and for I/O completion detection, neither of which is needed for a memory-mapped device. -------------------------------------------------------------------------------13.5 Why might a system use interrupt-driven I/O to manage a single serial port, but polling I/O to manage a front-end processor, such as a terminal concentrator? Answer:

Polling can be more efficient than interrupt-driven I/O. This is the case when the I/O is frequent and of short duration. Even though a single serial port will perform I/O relatively infrequently and should thus use interrupts, a collection of serial ports such as those in a terminal concentrator can produce a lot of short I/O operations, and interrupting for each one could create a heavy load on the system. A well-timed polling loop could alleviate that load without wasting many resources through looping with no I/O needed. -------------------------------------------------------------------------------14.1 None of the disk-scheduling disciplines, except FCFS, is truly fair (starvation may occur). A. Explain why this assertion is true. B. Describe a way to modify algorithms such as SCAN to ensure fairness. C. Explain why fairness is an important goal in a time-sharing system. D. Give three or more examples of circumstances in which it is important that the op- erating system be unfair in serving I/O requests. Answer: A. New requests for the track over which the head currently resides can theoretically arrive as quickly as these requests are being serviced. B. All requests older than some predetermined age could be "forced" to the top of the queue, and an associated bit for each could be set to indicate that no new request could be moved ahead of these requests. For SSTF, the rest of the queue would have to be reorganized with respect to the last of these "old" requests. C. To prevent unusually long response times. D. Paging and swapping should take priority over user requests. It may be desirable for other kernel-initiated I/O, such as the writing of file system metadata, to take precedence over user I/O. If the kernel supports real-time process priorities, the I/O requests of those processes should be favored. -------------------------------------------------------------------------------14.2 Suppose that a disk drive has 5000 cylinders, numbered 0 to 4999. The drive is currently serving a request at cylinder 143, and the previous request was at cylinder 125. The queue of pending requests, in FIFO order, is 86, 1470, 913, 1774, 948, 1509, 1022, 1750, 130 Starting from the current head position, what is the total distance (in cylinders) that the disk arm moves to satisfy all the pending requests, for each of the following disk- scheduling algorithms? A. FCFS B. SSTF C. SCAN D. LOOK E. C-SCAN F. C-LOOK Answer: A. The FCFS schedule is 143, 86, 1470, 913, 1774, 948, 1509, 1022, 1750, 130. The total seek distance is 7081. B. The SSTF schedule is 143, 130, 86, 913, 948, 1022, 1470, 1509, 1750, 1774. The total seek distance is 1745. C. The SCAN schedule is 143, 913, 948, 1022, 1470, 1509, 1750, 1774, 4999, 130, 86. The total seek distance is 9769. D. The LOOK schedule is 143, 913, 948, 1022, 1470, 1509, 1750, 1774, 130, 86. The total seek distance is 3319.

E. The C-SCAN schedule is 143, 913, 948, 1022, 1470, 1509, 1750, 1774, 4999, 0, 86, 130. The total seek distance is 9985. F. The C-LOOK schedule is 143, 913, 948, 1022, 1470, 1509, 1750, 1774, 86, 130. The total seek distance is 3363. -------------------------------------------------------------------------------14.7 Compare the performance of C-SCAN and SCAN scheduling, assuming a uniform distributionof requests. Consider the average response time (the time between the arrival of arequest and the completion of that request s service), the variation in response time, andthe effective bandwidth. How does performance depend on the relative sizes of seek timeand rotational latency? Answer: There is no simple analytical argument to answer the first part of this question. It wouldmake a good small simulation experiment for the students. The answer can be found inFigure 2 ofWorthington et al. [1994]. (Worthington et al. studied the LOOK algorithm, butsimilar results obtain for SCAN. Figure 2 in Worthington et al. shows that C-LOOK has anaverage response time just a few percent higher than LOOK but that C-LOOK has a significantlylower variance in response time for medium and heavy workloads. The intuitivereason for the difference in variance is that LOOK (and SCAN) tend to favor requests nearthe middle cylinders, whereas the C-versions do not have this imbalance. The intuitive reasonfor the slower response time of C-LOOK is the circular seek from one end of the disk to the farthestrequest at the other end. This seek satisfies no requests. It only causes a small performancedegradation because the square-root dependency of seek time on distance implies that a long seekisn t terribly expensive by comparison with moderate length seeks.For the second part of the question, we observe that these algorithms do not schedule to improverotational latency; therefore, as seek times decrease relative to rotational latency, the performancedifferences between the algorithms will decrease. -------------------------------------------------------------------------------14.9 Explain why SSTF scheduling tends to favor the middle cylinders of a disk over the innermost and outermost cylinders. Answer: The SSTF algorithm is biased toward the middle cylinders in much the same way the SCAN algorithm is. Since, in the SSTF algorithm, the closest cylinder is always chosen, then all middle cylinder references will serviced on the way to the end of the disk. I present the book's answer to this question, even though I think it is more muddled... just FYI:The center of the disk is the location having the smallest average distance to all other tracks. Thus the disk head tends to move away from the edges of the disk.Here is another way to think of it. The current location of the head divides the cylinders into two groups. If the head is not in the center of the disk and a new request arrives, the new request is more likely to be in the group that includes the center of the disk; thus, the head is more likely to move in that direction. --------------------------------------------------------------------------------------------------------------------------------------------------------------NOTES FROM CHAPTER 8 Deadlock -------------------------------------------------------------------------------A set of processes is in a deadlock state when every process in the set is waiti ng for an event that can be caused only by another process in the set. 8.2.1 Necessary Conditions A deadlock situation can arise if the following four conditions hold simultaneous ly in a system: 1. Mutual exclusion: At least one resource must be held in a nonsharable mode; that is, only one process at a time can use the resource. If another process re

quests that resource, the requesting process must be delayed until the resource has been released. 2. Hold and wait: A process must be holding at least one resource and waitin g to acquire additional resources that are currently being held by other process es. 3. No preemption: Resources cannot be preempted; that is, a resource can be re leased only voluntarily by the process holding it, after that process has comple ted its task. 4. Circular wait: A set {Po,Pi,..., Pn} of waiting processes must exist such tha t PO is waiting for a resource that is held by P\, P\ is waiting for a resourcet hat is held by P2, ..., Pn-\ is waiting for a resource that is held by P,,, and P,, is waiting for a resource that is held by PQ. 8.3 - Methods for Handling Deadlocks Principally, we can deal with the deadlock problem in one of three ways: - We can use a protocol to prevent or avoid deadlocks, ensuring that the system will never enter a deadlock state. - We can allow the system to enter a deadlock state, detect it, and recover. - We can ignore the problem altogether and pretend that deadlocks never occur i n the system. To ensure that deadlocks never occur, the system can use either a deadlock-preve ntion or a deadlock-avoidance scheme. Deadlock prevention is a set of methods fo r ensuring that at least one of the necessary conditions (Section 8.2.1) cannot hold. These methods prevent deadlocks by constraining how requests for resources can be made. Deadlock avoidance requires that the operating system be given in advance additi onal information concerning which resources a process will request and use durin g its lifetime. With this additional knowledge, we can decide for each request w hether or not the process should wait. To decide whether the current request can be satisfied or must be delayed, the system must consider the resources current ly available, the resources currently allocated to each process, and the future requests and releases of each process. If a system does not employ either a deadlock-prevention or a deadlock-avoidance algorithm, then a deadlock situation may occur. In this environment, the system can provide an algorithm that examines the state of the system to determine whe ther a deadlock has occurred and an algorithm to recover from the deadlock (if a deadlock has indeed occurred). Deadlock Prevention As we noted in Section 8.2.1, for a deadlock to occur, each of the four necessar y conditions must hold. By ensuring that at least one of these conditions cannot hold, we can prevent the occurrence of a deadlock. We elaborate on this approac h by examining each of the four necessary conditions separately. 8.4.1 Mutual Exclusion In general, however, we cannot prevent deadlocks by denying the mutual-exclusion condition, because some resources are intrinsically nonsha rable. 8.4.2 Hold and Wait To ensure that the hold-and-wait condition never occurs in the system, we must g uarantee that, whenever a process requests a resource, it does not hold any othe r resources. One protocol that can be used requires each process to request and be allocated all its resources before it begins execution. We can implement this provision by requiring that system calls requesting resources for a process pre cede all other system calls. An alternative protocol allows a process to reques t resources only when it has none. A process may request some resources and use them. Before it can request any additional resources, however, it must release a

ll the resources that it is currently allocated. Both these protocols have two main disadvantages. First, resource utilization may be low, since resources may b e allocated but unused for a long period. In the example given, for instance, we can release the tape drive and disk file, and then again request the disk file and printer, only if we can be sure that our data will remain on the disk file. If we cannot be assured that they will, then we must request all resources at th e beginning for both protocols. Second, starvation is possible. A process that needs several popular resources may have to wait indefinitely, because at least one of the resources that it needs is always allocated to some other process. 8.4.3 No Preemption The third necessary condition is that there be no preemption of resources that h ave already been allocated. To ensure that this condition does not hold, we can use the following protocol. If a process is holding some resources and requests another resource that cannot be immediately allocated to it (that is, the proces s must wait), then all resources currently being held are preempted. In other wo rds, these resources are implicitly released. The preempted resources are added to the list of resources for which the process is waiting. The process will be r estarted only when it can regain its old resources, as well as the new ones that it is requesting. Alternatively, if a process requests some resources, we first check whether they are available. If they are, we allocate them. If they are not, we check whether they are allocated to some other process that is waiting for additional resourc es. If so, we preempt the desired resources from the waiting process and allocat e them to the requesting process. If the resources are neither available nor hel d by a waiting process, the requesting process must wait. While it is waiting, s ome of its resources may be preempted, but only if another process requests them . A process can be restarted only when it is allocated the new resources it is r equesting and recovers any resources that were preempted while it was waiting. 8.4.4 Circular Wait The fourth and final condition for deadlocks is the circular-wait condition. One way to ensure that this condition never holds is to impose a total ordering of all resource types and to require that each process requests resources in anincr easing order of enumeration. 8.5 Deadlock Avoidance Deadlock-prevention algorithms, as discussed in Section 8.4, prevent deadlocks b y restraining how requests can be made. The restraints ensure that at least one of the necessary conditions for deadlock cannot occur and, hence, that deadlocks cannot hold. Possible side effects of preventing deadlocks by this method, howe ver, are low device utilization and reduced system throughput. An alternative method for avoiding deadlocks is to require additional informatio n about how resources are to be requested. For example, in a system with one tap e drive and one printer, we might be told that process P will request first the tape drive, and later the printer, before releasing both resources. Process Q, h owever, will request first the printer and then the tape drive. With this knowle dge of the complete sequence of requests and releases for each process, we can d ecide for each request whether or not the process should wait in order to avoid a possible future deadlock. Each request requires that in making this decision t he system consider the resources currently available, the resources currently al located to each process, and the future requests and releases of each process. The various algorithms differ in the amount and type of information required. Th e simplest and most useful model requires that each process declare the maximum number of resources of each type that it may need. Given this a priori informati on, it is possible to construct an algorithm that ensures that the system will n ever enter a deadlocked state. Such an algorithm defines the deadlock-avoidance approach. A deadlock-avoidance algorithm dynamically examines the resource-alloca tion state to ensure that a circular-wait condition can never exist.

8.6 Deadlock Detection If a system does not employ either a deadlock-prevention or a deadlock-avoidance algorithm, then a deadlock situation may occur. In this environment, the system must provide: - An algorithm that examines the state of the system to determine whether a dea dlock has occurred - An algorithm to recover from the deadlock 8.7 - Recovery from Deadlock When a detection algorithm determines that a deadlock exists, several alternative s are available. One possibility is to inform the operator that a deadlock has o ccurred and to let the operator deal with the deadlock manually. The other possi bility is to let the system recover from the deadlock automatically. There are t wo options for breaking a deadlock. One is simply to abort one or more processes to break the circular wait. The other is to preempt some resources from one or more of the deadlocked processes. 8.7.1 Process Termination To eliminate deadlocks by aborting a process, we use one of two methods. In both methods, the system reclaims all resources allocated to the terminated processe s. - Abort all deadlocked processes: This method clearly will break the deadlock cy cle, but at great expense; the deadlocked processes may have computed for a long time, and the results of these partial computations must be discarded and probab ly will have to be recomputed later. - Abort one process at a time until the deadlock cycle is eliminated: This meth od incurs considerable overhead, since, after each process is aborted, a deadloc k-detection algorithm must be invoked to determine whether any processes are sti ll deadlocked. 8.7.2 Resource Preemption To eliminate deadlocks using resource preemption, we successively preempt some r esources from processes and give these resources to other processes until the de adlock cycle is broken. If preemption is required to deal with deadlocks, then three issues need to be a ddressed: 1. Selecting a victim: Which resources and which processes are to be preempted? As in process termination, we must determine the order of preemption to minimize cost. Cost factors may include such parameters as the number of resources a dea dlocked process is holding and the amount of time the process has thus far consu med during its execution. 2. Rollback: If we preempt a resource from a process, what should be done with that process? Clearly, it cannot continue with its normal execution; it is miss ing some needed resource. We must roll back the process to some safe state and r estart it from that state. Since, in general, it is difficult to determine what a safe state is, the simple st solution is a total rollback: Abort the process and then restart it. Although it is more effective to roll back the process only as far as necessary to break the deadlock, this method requires the system to keep more in formation about t he state of all running processes. 3. Starvation: How do we ensure that starvation will not occur? That is, how can we guarantee that resources will not always be preempted from the same process? In a system where victim selection is based primarily on cost factors, it may h appen that the same process is always picked as a victim. As a result, this proc ess never completes its designated task, a starvation situation that needs to be dealt with in any practical system. Clearly, we must ensure that a process can b e picked as a victim only a (small) finite number of times. The most common solu

tion is to include the number of rollbacks in the cost factor. -------------------------------------------------------------------------------NOTES FROM CHAPTER 9 Memory Manegement -------------------------------------------------------------------------------Classically, the binding of instructions and data to memory addresses can be don e at any step along the way: - Compile time: If you know at compile time where the process will reside in m emory, then absolute code can be generated. For example, if you know that a user process will reside starting at location R, then the generated compiler code wi ll start at that location and extend up from there. If, at some later time, the starting location changes, then it will be necessary to recompile this code. The MS-DOS .COM-format programs are bound at compile time. - Load time: If it is not known at compile time where the process will reside i n memory, then the compiler must generate relocatable code. In this case, final binding is delayed until load time. If the starting address changes, we need onl y reload the user code to incorporate this changed value. - Execution time: If the process can be moved during its execution from one memo ry segment to another, then binding must be delayed until run time. Special hard ware must be available for this scheme to work, as will be discussed in Section 9.1.2. Most general-purpose operating systems use this method. With dynamic linking, a stub is included in the image for each library-routine r eference. The stub is a small piece of code that indicates how to locate the app ropriate memory-resident library routine or how to load the library if the routi ne is not already present. When the stub is executed, it checks to see whether t he needed routine is already in memory. If not, the program loads the routine in to memory. 9.1.5 Overlays To enable a process to be larger than the amount of memory allocated to it, we c an use overlays. The idea of overlays is to keep in memory only those instructio ns and data that are needed at any given time. When other instructions are neede d, they are loaded into space occupied previously by instructions that are no lo nger needed. The programmer, however, must design and program the overlay structure properly. This task can be a major undertaking, requiring complete knowledge of the stru cture of the program, its code, and its data structures. Because the program is, by definition, large-small programs do not need to be overlaid- obtaining a suf ficient understanding of the program may be difficult. For these reasons, the us e of overlays is currently limited to microcomputer and other systems that have limited amounts of physical memory and that lack hardware support for more advanc ed techniques. 9.2 - Swapping A process must be in memory to be executed. A process, however, can be swapped t emporarily out of memory to a backing store and then brought back into memory fo r continued execution. For example, assume a multiprogramming environment with a round-robin CPU-scheduling algorithm. When a quantum expires, the memory manager will start to swap out the process that just finished and to swap another proce ss into the memory space that has been freed (Figure 9.4). In the meantime, the CPU scheduler will allocate a time slice to some other process in memory. A variant of this swapping policy is used for priority-based scheduling algorith ms. If a higher-priority process arrives and wants service, the memory manager c an swap out the lower-priority process and then load and execute the higher-prio rity process. When the higher-priority process finishes, the lower-priority proc ess can be swapped back in and continued. This variant of swapping is sometimes called roll out, roll in. Normally, a process that is swapped out will be swapped back into the same memor y space that it occupied previously. This restriction is dictated by the method

of address binding. If binding is done at assembly or load time, then the proces s cannot be easily moved to a different location. If execution-time binding is b eing used, however, then a process can be swapped into a different memory space, because the physical addresses are computed during execution time. Whenever the CPU scheduler decides to execute a process, it calls the dispatcher . The dispatcher checks to see whether the next process in the queue is in memor y. If it is not, and if there is no free memory region, the dispatcher swaps out a process currently in memory and swaps in the desired process. It then reloads registers and transfers control to the selected process. The context-switch time in such a swapping system is fairly high. To get an idea of the context-switch time, let us assume that the user process is of size 1 MB and the backing store is a standard hard disk with a transfer rate of 5 MB per second. The actual transfer of the 1-MB process to or from main memory takes 1000KB/5000KB per second = 1/5 second = 200 milliseconds. Assuming that no seeks are necessary and an average latency of 8 milliseconds,the swap time is 208 milliseconds. Since we must both swap out and swap in, the tot al swap time is then about 416 milliseconds. 9.3 - Contiguous-Memory Allocation The main memory must accommodate both the operating system and the various user processes. We therefore need to allocate the parts of the main memory in the mos t efficient way possible. This section explains one common method, contiguous me mory allocation. The major factor affecting this decision is the location of the interrupt vector . Since the interrupt vector is often in low memory, programmers usually place t he operating system in low memory as well. Thus, in this text, we discuss only t he situation where the operating system resides in low memory. The development o f the other situation is similar. We usually want several user processes to res ide in memory at the same time. We therefore need to consider how to allocate av ailable memory to the processes that are in the input queue waiting to be brough t into memory. In this contiguous-memory allocation, each process is contained i n a single contiguous section of memory. 9.3.1 Memory Protection Before discussing memory allocation further, we must discuss the issue of memory protection-protecting the operating system from user processes and protecting u ser processes from one another. We can provide this protection by using a reloca tion register, as discussed in Section 9.1.2, with a limit register, as discusse d in Section 2.5.3. The relocation register contains the value ofthe smallest ph ysical address; the limit register contains the range of logical addresses (for example, relocation = 100040 and limit = 74600). With relocation and limit regis ters, each logical address must be less than the limit register; the MMU maps th e logical address dynamically by adding the value in the relocati on register. T his mapped address is sent to memory (Figure 9.5). When the CPU scheduler selects a process for execution, the dispatcher loads the relocation and limit registers with the correct values as part of the context s witch. Because every address generated by the CPU is checked against these regis ters, we can protect both the operating system and the other users' programs and data from being modified by this running process. For example, the operating system contains code and buffer space for device driv ers. If a device driver (or other operating-system service) is not commonly used , we do not want to keep the code and data in memory, as we might be able to use that space for other purposes. Such code is sometimes called transient operating -system code; it comes and goes as needed. Thus, using this code changes the siz e of the operating system during program execution. 9.3.2 Memory Allocation Now we are ready to turn to memory allocation. One of the simplest methods for m emory allocation is to divide memory into several fixed-sized partitions. Each p artition may contain exactly one process. Thus, the degree of multiprogramming is

bound by the number of partitions. In this multiple-partition method, when a pa rtition is free, a process is selected from the input queue and is loaded into t he free partition. In the fixed-partition scheme, the operating system keeps a table indicating whi ch parts of memory are available and which are occupied. Initially, all memory i s available for user processes and is considered as one large block of available memory, a hole. When a process arrives and needs memory, we search for a hole la rge enough for this process. If we find one, we allocate only as much memory as is needed, keeping the rest available to satisfy future requests. This procedure is a particular instance of the general dynamic storage-allocatio n problem, which concerns how to satisfy a request of size n from a list of free holes. There are many solutions to this problem. The first-fit, best-fit, and w orst-fit strategies are the ones most commonly used to select a free hole from t he set of available holes. First fit: Allocate the first hole that is big enoug h. Searching can start either at the beginning of the set of holes or where the previous first-fit search ended. We can stop searching as soon as we find a free hole that is large enough. - Best fit: Allocate the smallest hole that is big enough. We must search the entire list, unless the list is ordered by size. This strategy produces the sm allest leftover hole. - Worst jit: Allocate the largest hole. Again, we must search the entire list, unless it is sorted by size. This strategy produces the largest leftover hole, which may be more useful than the smaller leftover hole from a best-fit approach . Simulations have shown that both first fit and best fit are better than worst fi t in terms of decreasing time and storage utilization. Neither first fit nor bes t fit is clearly better than the other in terms of storage utilization, but firs t fit is generally faster. 9.4 - Paging Paging is a memory-management scheme that permits the physical-address space of a process to be noncontiguous. Paging avoids the considerable problem of fitting memory chunks of varying sizes onto the backing store; most memory-management sc hemes used before the introduction of paging suffered from this problem. The pro blem arises because, when some code fragments or data residing in main memory ne ed to be swapped out, space must be found on the backing store. The backing stor e also has the fragmentation problems discussed in connection with main memory, except that access is much slower, so compaction is impossible. Because of its a dvantages over earlier methods, paging in its various forms is commonly used in most operating systems. 9.4.1 Basic Method The basic method for implementing paging involves breaking physical memory into fixed-sized blocks called frames and breaking logical memory into blocks of the same size called pages. When a process is to be executed, its pages are loaded i nto any available memory frames from the backing store. The backing store is div ided into fixed-sized blocks that are of the same size as the memory frames. The hardware support for paging is illustrated in Figure 9.6. Every ad dress gene rated by the CPU is divided into two parts: a page number (p) and a p age offset (d). The page number is used as an index into a page table. The page table contains the base address of each page in physical memory. This base addre ss is combined with the page offset to define the physical memory address that i s sent to the memory unit. The paging model of memory is shown in Figure 9.7. T he page size (like the frame size) is defined by the hardware. The size of a pag e is typically a power of 2, varying between 512 bytes and 16 MB per page, depen ding on the computer architecture. The selection of a power of 2 as a page size makes the translation of a logical address into a page number and page offset pa rticularly easy.

S-ar putea să vă placă și