CS 481: Solutions for Assignment #2

Problem 4. What happens under each of the following scheduling algorithms on a heavily overloaded system? Discuss average waiting times of short, medium, and long jobs as we go from light to heavy loads. The question is rather vague. It says little about the nature of the jobs (I/O bound or CPU bound?), which would have at least as much effect at their length.

• FCFS. The load affects the length of the queue. Waiting time is waiting for all processes ahead in the queue to complete their turn; but it is compounded by I/O requests. Thus the length of a job has no effect on its waiting time, but the number of resource requests is makes is the key: at reach resource request, it has to go round the queue again. Thus jobs with a lots of resource or I/O requests suffer enormously, while pure CPU jobs suffer least. However all jobs will eventually terminate.
• HRRN. Total job length has little to do with this scheduling policy; the key parameter here is waiting time. Because job length is a constant, waiting time eventually dominates the response ratio and ensures that each job gets scheduled. However, job length is usually measured as time used up so far (because total job length is normally not known); thus it too can grow with time, so that very long jobs with frequent resource requests may accumulate enormous waiting time without getting high priority---they keep getting a bit of CPU between I/O requests. In any case, all jobs will eventually terminate.
• RR. The load affects the length of the queue. With a fixed quantum size, the number of times a job has to go round the queue is roughly proportional to its length---in contrast to FCFS, where it is roughly proportional to its number of I/O or resource requests. Thus longest jobs suffer most, shortest jobs least---for very short jobs with little or no I/O, RR looks like FCFS. However all jobs will eventually terminate.
• Multiple queues. That is vague to say the least. Assume, however, that it describes our standard multilevel feedback queue system, where quanta increase as priority decreases and where a job "sinks" when it uses up its quantum and rises when it does not. If new jobs are fed fairly high in the queue system (as is typical), then it is again possible for jobs never to finish---they sink low in a few CPU quanta, then get constantly bypassed by new jobs that never use up their (short) quanta. Job length is not relevant.

  If we have an aging system or a system that ensures drawing from lower-level queues every now and then, then we have a system where every job is guaranteed to finish. Again, total job length is not directly relevant---the system is based on quantum utilization; however, long jobs often have longer CPU bursts and so are seriously disadvantaged, but at least will eventually finish.

• Priority. The load affects the length of the queue. Job length is unrelated to priority and priority may be unrelated to I/O calls vs. CPU use, so job length does not affect behavior. Low priority jobs suffer most, while high-priority jobs go through quickly even under high loads. If priorities are very uniform, this looks like FCFS. Sine high-priority jobs can keep slipping ahead of low-priority ones, this is a system where we have no guarantee that a job will eventually be run -- very poor!
• SJF. There are two kinds of SJF: one which is based on a priori estimate of job lengths and one which estimate the next CPU burst base on an average of the recent ones and schedules in increasing order by length of CPU bursts. The second is the normal one in a computer system, since the first requires information that is usually unavailable, but the text suggests the first. With prior knowledge of job lengths, we have a priority scheme where priority is based on length of jobs. It behaves exactly like our priority system and thus cannot ensure termination of jobs. Short jobs do well, but long jobs may not ever get access to the CPU. Under the second scheme (average of recent CPU bursts), we have a more versatile system, in that the priority of a job keeps varying; heavily interactive jobs are highly favored, so much so that large, CPU-bound jobs may never terminate.

Problem 5. Give a non-computer example of preemptive and of nonpreemptive scheduling. It is easy to think of nonpreemptive scheduling: almost any queueing will do, such as a bank or grocery store queue. There may be external interrupts that take the job (a customer) off the processor (the clerk) for quick interrupt servicing (a phone call, for instance), but not preemption, because the processor is always returned to the job until the job is completed. A true preemptive example is harder. We want an example where a job is taken off the processor after using a certain amount of time, but may return later for more time. Preemption is not just any interrupt: it is an interrupt by which a process actually loses its turn. But appointments are often based on preemptive scheduling (it's really deadline scheduling): even if your business is not over when the time scheduled for the appointment is over, you have to leave and possibly make another appointment to finish your business. Again, interrupts may occur during the appointment (such as a phone call), but, as long as the processor (lawyer, physician) returns to you, this not true preemption. If the physician is called to the bedside of a desperate patient, however, and tells you that she won't be able to return and that you should come back some other day, then that is also real preemption. In an emergency room, the physician rotates her time among the patients, giving higher priority to the more critically sick or injured ones; the system behaves much like a round-robin with priority-based quantum sizes and definitely uses preemption.

Problem 7. In a deadline scheduling system, job A's deadline occurs before job B's. Prove that we should run A before B, that is, prove that, if running A before B fails to meet one deadline, running B before A will also fail to meet one deadline. Let the current time be 0, without loss of generality. Denote the deadlines by dA and dB and the execution times by tA and tB, respectively. We are given dA < dB. If the first schedule fails a deadline, it fails that for A or that for B. If it fails dA, it will also fail dA in the second schedule, since A terminates later in the second schedule than in the first. If it failed dB in the first schedule, then we have tB+tA > dB > dA; but then the second schedule, which completes A after tA+tB time units (i.e., when the first schedule completes B), fails dA.