CS 537 Project 2 - CPU Scheduling

CS 537 Project 2
CPU Scheduling in Java

Project Due Date: July 10, 2001
For this project, you are allowed to work with one partner.

Objective
One of the most important jobs of a modern operating system is managing the various processes in the system. The goal of any management scheme should be to provide a low system response time and high overall throughput of jobs. The policy should also prevent starvation, be fair to the various processes, and efficiently utilize the systems resources. Obviously, some scheduling policies are better at achieving these goals than others. In this project you will investigate five different scheduling algorithms and their effects on response time, throughput, and fairness.

Project Description
Your mission (should you choose to accept it) is to design and implement four different schedulers. These include:

First-Come, First-Serve (FCFS)
Shortest Job First non-preemptive (SJFnp)
Shortest Job First preemptive (SJFp)
Predicted Shortest Job First non-preemptive (PSJFnp)

You will also be required to report on the performance of a Round-Robin (RR) scheduler, but this scheduler has been provided for you.

You will be required to use a very basic simulator for this project. The source code can be found at:

~mattmcc/public/classes/cs537/p2/

After copying the simulator to your own directory, you can go ahead and run it immediately. Just type make and the source will be compiled and then the simulator will be run. By default, the system uses the fully functional Round-Robin scheduler that is provided for you. When you run the program, you will notice a few initial lines of output to the sceen followed by an assortment of statistics. These statistics show the average queue lengths at the CPU and at the disk. It also shows a number of other useful statistics that you can use to analyze the performance of each scheduling algorithm.

You will NOT need to modify any of the code already provided for you. You will definitely need to read and understand this code, but please do not change any of it. The one exception to this is the Makefile. Basically, whenever you want to test a particular scheduler, just change the necessary lines in the Makefile and type make. The Makefile is pretty well documented to show you what changes to make.

You will also find a file called data.mm1.120.100.5000.This file is a trace of actual process activity on a real system. Each line of this file contains three columns. The first column is the time when a particular process enters the system. The second column shows how long the process needs to run on the processor, and the third column indicates how many visits the process must make to the disk. It is this file that will be used to test your schedulers.

So how do you go about generating your own schedulers? You will create your own scheduling classes. These classes will be very similar to the RRScheduler.java file provided for you. Like RRScheduler, all of your scheduler classes MUST inherit the Scheduler class. Each scheduler must also provide the methods listed in the following table.

public boolean add(Job newJob, Job currentJob) Called by the simulator to add a new Job object to the queue of jobs waiting to use the processor. This method must also accept the current Job object being executed on the processor. If the new job should preempt the current job, this method will return true. Otherwise it returns false. Notice, this method does not actually remove the current job or start the new job - it simply tells the simulator what it should do.

public Job remove() Called by the simulator to remove a Job object from the queue of jobs waiting to use the processor. The Job selected should be the best job to run based on the scheduling policy being implemented. Again, note this method does not actually start the job running - the simulator will do that.

public boolean reschedule(Job currentJob) Called by the simulator to see whether or not the current job should be preempted. Note that this method does nothing other than decide if a job should be preempted or not - it does not actually do the preemption. If this method returns true, the simulator will then call the add and remove methods to actually remove the job and find out which job should run next.

public void printQueue() Prints information about the current queue. You can simply cut and paste this method from the RRScheduler.java file.

public String toString() Prints out the information for a given scheduling object. Again, you can cut and paste the method from RRScheduler.java.

You can obviously add other methods to your scheduling class if you would like. You can also add more classes to your program than just the scheduler classes that are required. A description of what each of these schedulers should do is listed in the following table. It is recommend that you try to implement the schedulers in the order they are listed.

First-Come, First-Serve This scheduler does exactly what it says - jobs are scheduled in the order that they appear to the scheduler. This policy will never preempt the currently running job.

Shortest Job First non-preemptive When the simulator calls the remove method, this scheduler should return the Job that will have the shortest CPU burst. To implement this and the next technique, you are allowed to "cheat" to determine the shortest CPU burst. Simply call the burstRemaining() method for each Job object in the queue. burstRemaining() returns the amount of time left for a particular jobs CPU burst. This method basically allows you to look into the future. In a real system, you would not have access to this information. This policy will never preempt the currently running job.

Shortest Job First preemptive This is exactly like the previous technique (SJFnp) except it is even more aggressive in scheduling jobs. If a new job is added to the system whose next CPU burst is less than the time remaining on the current jobs burst, the new Job should be scheduled. To make this happen, your add method should return true if the newJob has a shorter burst than the currentJob. Be careful, though, to make sure that you compare the new jobs burst time to that remaining on the current jobs (as opposed to the total burst time for the current job). This policy will occassionally preempt the currently running job.

Predicted Shortest Job First non-preemptive This policy is very similar to the SJFnp policy above - the next job to run is the one with shortest CPU burst. The difference is, in this scheduler you are not allowed to "cheat". You are required to use an exponential averaging function that uses the last burst time and the previous burst prediction to predict the next job to run. Unlike the previous two scheduling policies where you simply called the burstRemaining() method. This is a much more realistic technique and is how SJF could actually be implemented in the real world. To implement this technique, you will need to create a separate class that stores scheduling information for a Job and then assign an object of that type to the schedulerInfo field inside a particular Job object. DO NOT modify the Job class to implement this scheduling technique. This policy will never preempt the currently running job.

Before beginning to design your own schedulers, you should examine the simulator and Round-Robin schedulers and feel comfortable with how they work. This will be time very well spent and will save you many headaches down the road. For more information on each of the classes, you can check out the following javadocs:

Project Report
For this project you will be required to write a breif report discussing what you have learned about scheduling policies. You should run the following eight simulations:

Round-Robin with Quantum equal to zero.
Round-Robin with Quantum equal to 10.
Round-Robin with Quantum equal to 100.
Round-Robin with Quantum equal to 10000.
First-Come, First-Serve.
Shortest Job First non-Preemptive.
Shortest Job First Preemptive.
Predicted Shortest Job First non-Preemptive.

Your report should include such things as why different schedulers perform the way they do, the effects of different length quantums on a Round-Robin scheduler, the effects of preemptive versus non-preemptive scheduling, and how predicting job burst lengths differs from using the exact values.

Here is some additional information about your report:

Include the names of each partner on the first page of the report.
A hard copy of your report should be placed in Det Buaklee's mailbox or given to him in person.
Your report should be approximately one page long. Be brief and concise - not longwinded.

Handing in Your Project
The directory for handing in your program can be found at:

/p/course/cs537-mattmcc/public/username/p2

Pick one of the two partners handin directory to use. It does not matter which one. Once you have handed in the project, e-mail Det (det@cs.wisc.edu) to let him know the names of both partners and in which directory you have placed the project. You should hand in all *.java files which you created. You should not submit the *.java files we have provided for you. Also submit your Makefile. The Makefile should be configured to run the Round-Robin scheduler with a quantum of 100.

The last two items to submit are your project report and a README file that describes your files and how to run all of the schedulers. The README file should be handed into the handin directory with the rest of your files. The report, on the other hand, should be a printed hard copy handed into Det Buaklee's mailbox (or given to him in person). Remember, all assignments are due at 11:59 pm on the day indicated. At that time, you will no longer have permission to write to your directory (although you will still be able to read it). Let us know if you have any questions.

public boolean add(Job newJob, Job currentJob)	Called by the simulator to add a new Job object to the queue of jobs waiting to use the processor. This method must also accept the current Job object being executed on the processor. If the new job should preempt the current job, this method will return true. Otherwise it returns false. Notice, this method does not actually remove the current job or start the new job - it simply tells the simulator what it should do.
public Job remove()	Called by the simulator to remove a Job object from the queue of jobs waiting to use the processor. The Job selected should be the best job to run based on the scheduling policy being implemented. Again, note this method does not actually start the job running - the simulator will do that.
public boolean reschedule(Job currentJob)	Called by the simulator to see whether or not the current job should be preempted. Note that this method does nothing other than decide if a job should be preempted or not - it does not actually do the preemption. If this method returns true, the simulator will then call the add and remove methods to actually remove the job and find out which job should run next.
public void printQueue()	Prints information about the current queue. You can simply cut and paste this method from the RRScheduler.java file.
public String toString()	Prints out the information for a given scheduling object. Again, you can cut and paste the method from RRScheduler.java.

First-Come, First-Serve	This scheduler does exactly what it says - jobs are scheduled in the order that they appear to the scheduler. This policy will never preempt the currently running job.
Shortest Job First non-preemptive	When the simulator calls the remove method, this scheduler should return the Job that will have the shortest CPU burst. To implement this and the next technique, you are allowed to "cheat" to determine the shortest CPU burst. Simply call the burstRemaining() method for each Job object in the queue. burstRemaining() returns the amount of time left for a particular jobs CPU burst. This method basically allows you to look into the future. In a real system, you would not have access to this information. This policy will never preempt the currently running job.
Shortest Job First preemptive	This is exactly like the previous technique (SJFnp) except it is even more aggressive in scheduling jobs. If a new job is added to the system whose next CPU burst is less than the time remaining on the current jobs burst, the new Job should be scheduled. To make this happen, your add method should return true if the newJob has a shorter burst than the currentJob. Be careful, though, to make sure that you compare the new jobs burst time to that remaining on the current jobs (as opposed to the total burst time for the current job). This policy will occassionally preempt the currently running job.
Predicted Shortest Job First non-preemptive	This policy is very similar to the SJFnp policy above - the next job to run is the one with shortest CPU burst. The difference is, in this scheduler you are not allowed to "cheat". You are required to use an exponential averaging function that uses the last burst time and the previous burst prediction to predict the next job to run. Unlike the previous two scheduling policies where you simply called the burstRemaining() method. This is a much more realistic technique and is how SJF could actually be implemented in the real world. To implement this technique, you will need to create a separate class that stores scheduling information for a Job and then assign an object of that type to the schedulerInfo field inside a particular Job object. DO NOT modify the Job class to implement this scheduling technique. This policy will never preempt the currently running job.

CS 537 Project 2 CPU Scheduling in Java

CS 537 Project 2
CPU Scheduling in Java