Round Robin Scheduling

Previous post discussed the two types of CPU Scheduling, Preemptive and Non-Preemptive CPU Scheduling and was focused with FCFS, SJF and Priority Scheduling techniques. We had discussed in the last post how SJF and Priority Scheduling could be modified to attain preemptive scheduling and why FCFS scheduling cannot be used as preemptive scheduling. This post will go further with another preemptive type of CPU Scheduling which is known as Round Robin CPU Scheduling. Now, as we already know Preemptive Scheduling means forcibly stopping a job from the execution and keep it in the waiting state/blocked state for a period of time until it finishes executing another job execution processing, Round Robin is another instance of Preemptive Scheduling wherein it is possible to stop the job and pick up another job from the READY QUEUE and start executing it. But there is a difference in the way Round Robin Scheduling in implemented.

In SJF (modified to SRT {Shortest Remaining Time First Scheduling}) and Priority (modified with LONG TERM and SHORT TERM Scheduler), it was possible to attain preemptive CPU Scheduling, and used time (CPU BURST TIME) and priority respectively; this however isn’t the case with Round Robin Scheduling (does not depend on CPU BURST Time of the job, or the priority of the job. All the jobs are treated equally). Round Robin Scheduling, the CPU time is divided into number of quanta. Assume the CPU quanta to be duration = 2 ms (Milli-Second). Now, whenever a job is allocated to the CPU for execution, the job will be executed for a maximum of 2 ms. If the CPU BURST time required for the job execution to be completed is more than 2 ms, after 2 ms the job will be forcibly terminated and pushed back to the READY QUEUE and the new job from the READY QUEUE will be allocated to the CPU for execution and again that this new job will be only until 2 ms since that is the quanta defined in terms of Round Robin CPU Scheduling. In case the job execution requirement for any job is less than 2 ms, the job terminates normally and not forcefully. So after termination of the the job in case the job finishes before 2 ms, the Job might go to the I/OWAITING STATE/BLOCK STATE for the CPU to handle I/O operations or might go to the HALTED STATE/TERMINATED STATE. The CPU can’t stay idle for the remaining time if the jobs has finished before the determined quanta, hence the best efficient applied as per Round Robin implementation is to take a new job and start executing the job from that point of time and hence save time with efficiency. This means, assume if the quanta is 2 ms and the job was finished in 1 ms, a new job from the READY QUEUE is taken by the CPU Scheduler and executed, this new job quanta time starts from the earlier saved time which was 1 ms (2-1 = 1 ms). So for an example, there are 4 jobs in the READY QUEUE to be executed by the CPU :

J1 = 4 ms
J2 = 2 ms
J3 = 3 ms
J4 = 6 ms

Assumption is CPU quanta to be 2 ms. That is 1 quanta = 2 ms. Now for Round Robin CPU Scheduling, the job is taken as FCFS basis, but a limited quanta is available for all the jobs per execution cycle, that is in this case 2 ms (1 quanta). The timeline, these jobs will be served is as follows:

Since, Round Robin CPU Scheduler is taking the jobs in FCFS (First Come First Served) basis, there is no priority or CPU time burst minimum time required job first assigned with the scheduling process. The allocation is done purely on first come, first served basis this way and each execution cycle for each job spends 1 quanta of time that is 2 ms which is in this case. After 1 quanta of time spent on a particular job, the job if remaining CPU BURST remains, get’s to the READY QUEUE and next job is taken. If this next job is processed and only required the exact processing time equal to that of the 1 quanta time, the job can either be pushed to the I/O WAITING STATE to cover I/O operation or might reach the HALTED STATE/TERMINATED STATE which is normal Job execution termination. If the Job has finished before the 1 quanta time, the CPU Scheduler without wasting any time pushes the next job from the READY QUEUE to the ACTIVE STATE and starts executing it until the 1 quanta time period which is being assigned similarly to other jobs. When jobs are pushed to the READY QUEUE, they always are pushed to the back of the READY QUEUE since other jobs which are finished first should be at the first to be taken by the CPU. This means the CPU takes the job from the READY QUEUE head, which again means it is following all the rules of the FCFS basis. It has also to be noted that jobs could be pushed to the READY QUEUE from the I/O WAIT STATE, NEW STATE, or ACTIVE STATE (in-case of forcible termination). Here, we need to look at the process diagram to verify if the jobs could be taken to the READY QUEUE in three ways:

The process state diagram suggests, that indeed the READY QUEUE (READY STATE as per process state diagram) get’s the jobs from all the three directions, that is the active state when forcible termination of job is done by the CPU, the new state when new arrivals of jobs are scheduled to be transferred from the new state to the ready state and the wait or blocked state when the jobs are awaiting I/O operations. Hence, after the first execution cycle, the timeline for the above example would look like this:

Now, after this timeline, all the JOBS will be completed assuming no new job arrivals were in the READY QUEUE from the NEW STATE. Hence all the jobs are treated equally in the Round Robin CPU Scheduling. There must be a timer in the system to remind the CPU what 1 quanta is over for a job, this brings the topic to a new curve. The timer we are talking about here could be programmable as well since in some installations, an administrator might want a small quanta, in other installations, the same administrator might want a higher quanta. SO this timer should be programmable, to interrupt the processor reminding the CPU that 1 quanta is past and a job must be stopped.

Timer (Programmable)

Whenever the CPU Scheduler decides that a new job has to be allocated to the CPU or the CPU allocates a new job for execution, immediately the timer has to be reset. At the end of the time pointer, the timer will generate an interrupt when again the CPU will go to the system program and the responsibility of that system program will be to terminate the current executed job, get a new job from the READY QUEUE, give it to the CPU for execution and re-start the timer. That is what happens when the required CPU BURST time in more than the quanta set in the timer. If the CPU BURST time is less then that of the quanta described in the timer, the process is not executed completely till the timer gives an interrupt. The execution is completed before the timer gives an interrupt but the process for the whole cyclic execution process is not yet completed wholly. So the last statement of every CPU BURST must be a system call. The system call for performing an I/O operation or a system call indicating that the process is complete. Again following the system call, the CPU Scheduler has to fetch a new process (job) from the READY QUEUE, give it to the CPU for execution and at the same time, the timer has to be reset so that the next time quanta starts from that point.

Variations of Round Robin Scheduling

There could be different variations of the Round Robin Scheduling, earlier there were no considerations on the Round Robin Scheduling but there could be Jobs which require more CPU BURST time duration depending if the CPU BURST time is more for I/O Operations (I/O Bound Jobs) or CPU Time (CPU Bound Jobs). The variation will depend on these CPU BURST time duration requirements! The main algorithm used will be Round Robin Scheduling.

To implement these concepts, there is a need to know MULTI-LEVEL QUEUE

MULTI-LEVEL QUEUE

There could be multiple READY QUEUE’s as such the following demonstrating how it would work:

The entire diagram suggests that there could be multiple READY QUEUE which could be taken into consideration depending upon the jobs since the variation of jobs have either I/O operation taking the CPU BURST or CPU time taking the time duration of the CPU Processing. This way, if efficiency has to be maintained such that I/O Operations are given the highest priority, the multiple READY QUEUE would have (for an example) 1 READY QUEUE divided into 3 READY QUEUE, they could be:

Q1

Q2

Q3

Here are the Jobs which would be as per the priority of execution (Round Robin Scheduling Implementation does not use Priority, here we are only giving the job prioritizing the jobs in the READY QUEUE not in the Scheduling Algorithm).

Q2 – only after Q1 is empty, the jobs in Q2 are taken. That is all I/O Bound jobs have to be completed first.

Q3 – only after both Q1 and Q2 are empty, the jobs pending on Low priority that is CPU Bound jobs are taken.

There are disadvantages here. Consider that the jobs could be dynamic in nature which means, a job which is an I/O Bound Job could be changed into requiring CPU time (converts itself into being CPU Bound Job). That way, with the current MULTI-LEVEL QUEUE implementation, the jobs in the Q1 (requiring to be executed first in order) in-spite the jobs being transformed to CPU Bound Job by being of Dynamic Nature has to be in the Q1 and executed in first preference. This is unwanted and there has to be some techniques to resolve this. This is where MULTI-LEVEL FEEDBACK QUEUE is used.

MULTILEVEL FEEDBACK QUEUE

In Multilevel feedback queue, there would be again multiple number of queue’s. Assume there are 3 queues as shown below in the diagram (but with a provision that the jobs could be taken from one queue to another queue).

Whenever the jobs are pushed into the READY QUEUE, it’s always taken to the QUEUE number 1 which is Q1. The time quanta for all the queue’s are:

Q1 = 2 ms

Q2 = 5 ms

Q3 = 10 ms

Whenever a job is entered the first time, let’s assume the nature of the jobs isn’t known that is whether the Job is I/O Bound Job or a CPU Bound Job (what will be the CPU BURST Duration). In queue number 1, the job is to be put. In queue number 1 (Q1) the jobs will be allocated to the CPU using Round Robin Scheduling, for execution of the job. Once it is allocated to the CPU, it will be executed for a minimum of 2 ms, if one fins that the job (The CPU BURST) is over is finished before 2 ms, the job will be kept in Q1 and would not be moved to Q2. This is because the first it has executed, it has shown that the CPU BURST requirement is less than 2 ms, so it’s predicted that the next CPU BURST time will also be less than 2 ms. If the CPU BURST time of the Job is less than 2 ms, the Job remains in Q1. If the timer trigger has occurred and the job is greater than 2 ms, the job will be pushed to next queue which is Q2 which has the time quanta of more than 2 ms. This will again follow the Round Robin CPU Scheduling technique for the job to be allocated to the CPU for execution. This time the time quanta is 5 ms in Q2. In Q2, if one fins that the CPU time requirement for the job is less than 5 ms, it will remain in Q2 itself. Otherwise if it is greater than 5 ms, it will be pushed to the next queue which is Q3, with time quanta 10 ms. All of these queue will follow the Round Robing CU Scheduling algorithm for CPU jobs allocation for job execution.

So conclusively, the first time the job is pushed to the Q1, if the job CPU BURST duration is grater than the current quanta threshold of that particular queue, it would be pushed to the second queue or else be retained there itself. This depends on the nature of the jobs depending upon the requirement of the jobs for the time duration needed for a complete execution of the job with levels of time quanta divided into the READY QUEUE since the QUEUE itself now has been divided according to the time duration using quanta’s. In a similar fashion, the jobs which could be pushed downwards, should be the job require more I/O Bound Operations, the same should be the procedure, to push back the job upwards that is from Q3 to Q2 and then Q2 to Q1 as per the requirement and the nature of the job (if dynamic!). This means if the job at some point of time remain to be I/O Bound, the job remains in the Q1, if at another point of time duration. the job changes it’s nature from I/O Bound to CPU Bound, it could be pushed downward (lower preference). Similarly, low priority jobs (CPU Bound Jobs) could be pushed upwards by increasing it’s priority as per the dynamic nature of the job (changes from CPU Bound job to I/O Bound Job). Hence Jobs are kept at the queue level according to the nature of the job. These are the variations of the Round Robin Technique.

The diagram above shows clearly how the jobs are now flexibly aligned in accordance to the time duration required and the dynamic nature of the job. If the jobs are changed from CPU Bound job to the I/O bound, it’d go upwards the direction and if the I/O bound jobs are changed to CPU Bound jobs, it’d move downwards the direction as per the requirement. I/O Bound Jobs have the highest priority since it requires less CPU BURST time duration than the CPU bound Jobs which requires more CPU BURST time duration and hence has a lower priority.

A feedforward is also used, since there is a concept called switch time which is the extra time required by the CPU to change from a queue to another queue. The queue could be switched directly to the appropriate queue without having them to move through the intermediate queue. This means if a job has to be transfer from the Q3 to Q1, it is directly possible but needs switch time and some extra CPU processing. This is demonstrated in the diagram below:

We have concluded over preemptive and non-preemptive CPU Scheduling from the last post and concluded this with Round Robin CPU Scheduling. All the posts which covered process management are:

FCFS (First Come First Served) – Nonpreemptive

SJF (Shortest Job First) – Nonpreemptive

Priority Scheduling – Nonpreemptive

SRT (Shortest Remaining Time First) – Preemptive

Round Robin Scheduling – Preemptive

Multilevel Queue – Preemptive

But all these CPU Scheduling which we have discussed are based on a single CPU. The modern operating systems should not remain satisfied with single processor CPU. There are distributing computing nature which is used in modern operating system be it networked processors among many systems or a single set-up having multiple core processors. We discussed single resource with multiple processes among which the resource is to be shared. What we will see next is a setup wherein there are multiple resource which is to be shared with multiple processes.

DISTRIBUTED COMPUTING

There are models which could go under distributed computing:

WORKSTATION MODEL

PROCESSOR POOL MODEL

Workstation Model could be considered as such every user which has one full fledged computer having it’s own memory, hard-disk, etc but shared on for example a LAN network without which the the computer remains functional. Every user has the processing power.

Processor Pool Model could be considered wherein one can have a high-end server having multiple processors and to the users, there could be high-end terminals (example a graphics terminal), so that the user terminal doesn’t have any processing capabilities. Users does not have processing capabilities, the processing is centralized.

Naturally for these two types of models, the approach taken for CPU sharing must be different. There hence must be two different kind of allocation techniques:

NON-MIGRATORY

MIGRATORY

NON-MIGRATORY to some extend is static in nature. In NON-MIGRATORY CPU allocation, once the process is created, it is decided on which of the processors the process has to be executed; once decided it is fixed and that process is executed on that processor until termination.

MIGRATORY is dynamic wherein the process could be migrated from one processor to another depending upon the requirement. The process itself hence could be terminated in another processor and could be originated or allocated to another processor during initiation of the process.

The next post would cover these aspects of CPU process sharing since this post was dedicated to cover Round Robin Scheduling and Multilevel Queue. Single CPU Management and Process Management hence has been covered in these five posts which could be used for a ready reference: