CS411/511. Operating Systems
Spring 1999

Project #1: CPU Scheduling

Due at 9:00 AM on Friday, April 23.


For this project, you'll modify an implementation of Round-Robin (RR) CPU scheduling algorithm so that it uses Shortest-Remaining-Time-Next (SRTN), the preemptive version of Shortest-Job-First discussed in class.

As we discussed, one of the key problems is how to estimate a process's "remaining time," or next CPU burst. To do this, you will be calculating an exponential average of the measured lengths of previous CPU bursts. The method is described on pp. 131-132 of the text. Use an alpha value of 0.30 in your equation.

Once you have implemented SRTN, you will compare the resulting statistics with those you obtained using the original RR version.


Turn in:

  1. Source code and a simulation run, using the hand_in script described below.
  2. A typed memo (1 page expected, 2 page maximum) emailed to cs411@engr.orst.edu. Explain your decisions and how well they worked out, including at least: Also include a table of the results you obtained (raw numbers, means, and standard deviations) by running 5 simulations each for the RR and SRTN versions, using heavy.parms. The statistics we're interested in are CPU utilization, system throughput, average waiting time, and average turnaround time. Explain your results and how you think the algorithm would work in a real-life implementation.


Building and executing the simulation

In OSP, CPU scheduling involves the functions in file cpu.c. The diagram at the end of this document indicates how OSP interacts with the functions in cpu.c, specifically insert_ready (which adds the PCB to the ready queue) and dispatch (which removes a PCB from the queue and dispatches it). These two routines are where you will be concentrating your efforts. Don't add global variables unless they are really necessary; but if so, they should go just prior to cpu_init. You will need to use cpu_init (which is called when OSP is set up) to initialize those global variables.

Copy the seven files indicated below into your own directory:

	~cs411/asst1.hp700/Makefile
	~cs411/asst1.hp700/OSP.demo
	~cs411/asst1.hp700/cpu.c
	~cs411/asst1.hp700/cpu.h
	~cs411/asst1.hp700/dialog.c
	~cs411/asst1.hp700/light.parms
	~cs411/asst1.hp700/heavy.parms
Notice that Makefile compiles cpu.c, cpu.h, and dialog.c, while light.parms and heavy.parms are parameter files. OSP.demo is a compiled executable that does RR scheduling. The only file you should have to modify is cpu.c (and optionally dialog.c). Modifying the other files will probably "break" OSP.

Compile and link the program with the make command. This will create an executable called OSP. Run the simulator with the following command:

	> OSP light.parms
The values in light.parms provide a "quick-and-dirty" test that you can use while developing and debugging your cpu routines. The final simulation runs must be made using heavy.parms. The simulation run you hand in must also use heavy.parms.


How CPU Scheduling Fits with the Rest of OSP

Whenever a new process enters the system (numbers refer to the figure):

Whenever the CPU becomes idle (process terminated, blocked, had timerrunout, or generated a page fault):


Tips for Doing Your Assignment

Here are some PCB fields that may be useful:

last_cpuburst amount of time used during last shot at CPU
accumulated_cpu cumulative CPU time up till now
hook a place to add your own information (note: you must allocate memory for this!)
Be sure to explain your design decision in the report.

Be very careful that you do not leave a PCB in the ready queue when it is dispatched. If you do, and then re-insert it after a timerrunout or block, the queue may become disconnected, making some ready processes inaccessible. These stranded processes can never be re-scheduled, so the statistics will be skewed.

Debugging hint: You may want to create a function to display your ready queue linked list. The routine would display the id of each process and the calculated mean value for that process. Then if you print out the ready queue at the beginning and end of insert_ready(), you will be able to see if your queue is ordered correctly or not.

Debugging hint: In the event you are core dumping and the simulation.run file is empty, switch the parameters file to interactive mode (change the last 'n' to a 'y'). In interactive mode, you'll at least be able to see your debugging output before the world comes crashing down.

Survivial hint: Since you need to turn in something that compiles and runs, you may want to work up to the final solution in stages. A good way to start would be to change the RR algorithm into one that schedules the process with the smallest last_cpuburst. Once you have this working, then change the scheduling to be based on the adjusted mean.

Warning: Be careful with the hook field! It is only declared in the PCB as a pointer. You are responsible for allocating memory if you want to store something there. When accessing the hook, make sure you are dereferencing the pointer to get to the actual number stored there and not just the memory address.

While the pcb struct is declared in cpu.h, it is also declared elsewhere in the OSP code. You cannot add or change fields in the pcb struct. You will core dump.

So the only way to add information to a pcb record is by using the hook. In this assignment, you will probably need a double or float associated with each pcb. You must malloc an appropriate amount of memory for the hook before you use it. A process coming into insert_ready with an accumulated_cpu time of 0 is a brand new process.

To assign a new value to the hook without having the result cast down to an int, you'll have to employ a pointer to a double (or float), and use this temporary variable for the assignment:

double *dbl_ptr;
dbl_ptr = (double *) pcb->hook;
*dbl_ptr = 123.4242;

The above code will put the value 123.4242 into the hook field of the pcb.


Turning in Your Assignment

When you are satisfied that your cpu scheduling algorithm works, use the hand_in script to submit your project. Be sure you have made several runs using the heavy.parms parameter file. Bugs in your implementation may not show up under the light.parms parameter settings. For that reason, assignments which are handed in using the light.parms file are not acceptable.

To submit your project, use the following command from the directory where you source files are located:

	> ~cs411/asst1.hp700/hand_in 
This script will compile your source code and link it with OSP. Then it will prompt you for a parameter file. Use heavy.parms. Hand_in will run the OSP simulator and put a copy of your source code and a copy of the simulation results in a secure sub-directory in the cs411 directory. You can submit the assignment as many times as you want -- only the last submission will count. Earlier submissions are overwritten.

Remember to turn your assignment in on time. We don't accept late submissions, but we do give partial credit if the assignment actually runs and is on time.