13.07.2015 Views

An Operating Systems Vade Mecum

An Operating Systems Vade Mecum

An Operating Systems Vade Mecum

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

48 Time Management Chapter 23.1 Classification of scheduling policiesTo put the large number of scheduling policies in perspective, we can develop a languageto characterize the most important scheduling policies. We first want to distinguishpreemptive from non-preemptive methods. In the first, typified by RR, service can beinterrupted by various external events. We have seen the clock interrupt as one exampleof such an event. Other reasons for preempting the current process include new arrivalsin the ready queue and changes of priority within that queue. We will soon see methodsthat use such reasons. Under non-preemptive methods, typified by FCFS, service is interruptedonly when the process enters a wait list or terminates.Once it has been decided to start another process, the policy that selects the newprocess makes a priority decision: The most urgent process should run next. Policiesdiffer in how they compute urgency. In both RR and FCFS, priority is based on the orderof arrival in the ready queue. More generally, priority information may be based on thefollowing properties.Intrinsic properties: characteristics that distinguish one process from another.Intrinsic characteristics include service-time requirements, storage needs, resourcesheld, and the amount of transput required. This sort of information may be placedin the context block. For example, the MVS operating system for the IBM 370gives a longer quantum to processes holding certain resources. Tops-10 gives ahigher priority to processes using small amounts of main store, particularly if themain store is tied down, that is, prevented from being displaced by otherprocesses. (We discuss tying down in Chapter 3.)These characteristics might be determined either before the process starts or whileit is running. They may even change while the process is running. For example, inspooling and batch systems, service-time requirements may be explicitly declaredas part of the job description. For example, a user might indicate that this processneeds 45 seconds to complete. If it takes more, the operating system is justified interminating it. Even rough guesses can be useful to the operating system. Experienceshows that less than 10 percent of processes actually exceed estimates. Ininteractive multiprogramming, service time is usually not known (or evenestimated) before the process starts, but it may be estimated implicitly once theprocess has been running. Storage needs either can be declared explicitly ahead oftime or can be deduced implicitly by the operating system. Storage needs maychange during the lifetime of a process. Likewise, the user may declare explicitlywhich devices will be used, or the operating system can wait until the process startsperforming transput to record this property.Extrinsic properties: characteristics that have to do with the user who owns theprocess. Extrinsic properties include the urgency of the process and how much theuser is willing to pay to purchase special treatment.Dynamic properties: the load that other processes are placing on resources.Dynamic properties include the size of the ready list and the amount of main storeavailable.We can arrange the policies we have examined according to whether they usepreemption and whether they use intrinsic information. This arrangement is shown in

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!