CS411 - Project

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:

Source code and a simulation run, using the hand_in script described below.
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:
- How did you order your ready queue and why? If you didn't order the queue, explain how you selected the correct process to dispatch.
- Can processes starve under RR? Under SRTN? If so, how could you prevent this?
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):

(1) OSP creates a pcb (Process Control Block), then invokes your insert_ready() routine, sending it a pointer to the pcb
(2) insert_ready() adds the pcb to a ready queue in four steps:
- if a pcb that is already in the queue is inserted again, OSP will crash
- sets the pcb's status field to ready
- creates a new queue node for the process
- adds the node to the queue.

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

(A) OSP's context switcher invokes your dispatch() routine; there are no arguments, but the pcb of the process that just stopped can be found using PTBR->pcb (Page Table Base Register's entry for pcb)
(B) if that process was interrupted while it was still running, its pcb should be reinserted back into a ready queue via a call to your insert_ready() routine
(C) if the queue is empty, set the PTBR to null to indicate that no process is running, then return control to OSP
(D) otherwise, select a process, remove it from the queue, and dispatch it:
- peel off the next queue node and destroy it (but don't "lose" the pcb)
- set the pcb's status field to running
- record the time of the dispatch in the pcb's last_dispatch field
- set the timer to the quantum value via a call to set_timer()
- update the PTBR to point to the new process' page table, found in pcb->page_tbl

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.