Assignment 4: Process Scheduling and Memory Management

CMPT300: Operating Systems I

Due:
July 18, 2012 @ 10:00 pm.

The assignment consists of two parts: The theoretical part can be done in groups. The practical part
must be done in C/C++ individually, and is strictly subject to latency and plagiarism policies.

1 Theoretical Questions
1. Define the following terms precisely and briefly:
a. Multilevel Page Table
b. TLB
c. Best-fit algorithm
d. Memory Compaction

2. What is swapping? What are its shortcomings?

3. Explain the trade-off in choosing the block size in swapping.
4. Describe the concepts of “virtual memory”, “physical address”, “virtual address” and how the
“address translation” is accomplished.

5. How can we improve the performance of paging? Describe the alternatives and list their pros and
cons.
6. What is the difference between an inverted page table and a normal page table? When is it better
to use an inverted page table?

2 Practical Questions
Purpose
Implementation of different scheduling algorithms and measuring different performance criteria.

Question 1 - Scheduling Performance. Write a C/C++ program that given information about
arrival time and length of a number of processes, simulates the following scheduling algorithms:
1. First-Come-First-Served
2. Shortest Remaining Time Next
3. Round Robin (with given quantum)

4. Lottery Scheduling (with given quantum)

1
Your program should calculate any of the following evaluation criteria:
1. Throughput - number of processes that complete their execution per time unit;
2. Average Waiting Time - (Waiting Time: amount of time a process has been waiting in the ready
queue);

3. Average Response Time - (Response Time: amount of time it takes from when a request was
submitted until the the process starts running);
4. Average Turnaround Time.
5. Proportionality - the maximum ratio of the turnarround time to the expected running time;

Your program receives two command line parameters: first, path of an input file containing the
process information, and second, a positive integer to be used as the quantum for the round-robin and
lottery scheduling. The program has a tabular output, one row per criterion. In each line, the scheduling
algorithms are sorted from best to worst, with respect to the corresponding criterion. In a parenthesis
next to the name of the algorithm, the measured value should be displayed. For example, in the figure
below FCFS performed best w.r.t throughput (with value 0.001), then SRTN (with some other value),
and so on. Please follow exactly the same names for the algorithms and criteria, and do not output extra
text.

> ./a4q1 [input-file] [quantum]

Throughput: FCFS( 0.001) SRTN(x) RR(x) LS(x)

AWT: FCFS( x) SRTN(x) RR(x) LS(x)
ART: SRTN( x) FCFS(x) RR(x) LS(x)
ATT: FCFS( x) LS(x) SRTN(x) RR(x)
Proportionality: SRTN(x) RR(x) LS(x) FCFS( x)

The input file has the following format (t(i), and l(i) are arrival time, and length, of the process i
resp.):

t(1) l(1)
t(2) l(2)
.
.
.
t(n) l(n)

l m
l(i)
In lottery scheduling, assume each process i gets 2 · quantum tickets in the beginning.

Simplifying Assumptions The context switch time is always “1” time unit; The processes perform
no I/O. The input file and command-line parameters are error-free (no need for error messages). You
can assume n ≤ 105 .

2
 Question 2 - Real-time Scheduling. Implement the Earliest Deadline First (EDF) real-time
scheduling algorithms. Your program receives the path of the input file as a command line parameter.
The input file contains process information and has the following format ( t(i), l(i) and d(i) are arrival
time, length, and deadline of the process i, resp.):

t(1) l(1) d(1)

t(2) l(2) d(2)
.
.
.
t(n) l(n) d(n)

The program should output the scheduling information (starting time of each task), or in case the
real-time scheduling fails, output “Failed.”. Here is how the program looks like in the console (s(i) is the
first time the CPU is allocated to the process i):

> ./a4q2 [badInputFilePath]

Failed.
> ./a4q2 [goodInputFilePath]
s(1)
s(2)
.
.
.
s(n)

Please do not output extra information. The context switch time is assumed to be negligible
in the second question.

Hints
Good design plays an important role in this assignment. You may waste hours of your time if you do
not invest on the design phase. Before starting the implementation, first make sure you understand the
question and concepts thoroughly. Start from a high level design, then gradually refine it to get a list of
classes/functions/etc. There are many recurrent concepts in this assignment, so do your best to design
reusable components. You can even share components between your first and second program.

Submission
You are required to submit one “makefile” to compile/link your source code and generate executables.
After generating the executables using the makefile, I will use the executables to test the correctness of
your programs. If your makefile fails, you will lose a portion of the mark. Please follow the submis-
sion guidelines carefully, or otherwise you might lose marks. In case of significant deviation from the
specification, you will be asked to demo the assignment.
All the deliverables described below should be compressed in a .zip or .tar.gz file. When extracted,
the following files should appear:
• Files containing your source code; your code must work on CSIL machines.

3
 • Only one “makefile” that compiles your code and produces the executables. The executable files
must be named a4q1 (for question 1), and a4q2 (for question 2) with lowercase letters, and without
any extensions.
• A Readme file describing:

– whom you have helped and who have helped you;

– any bug/deviation from specification you could not resolve;
– any other comment you think is necessary for running and testing your program.
You can omit the Readme file if all the above items are empty.

Grading
(5% bonus)
• 45% Correctness of a4q1;
• 35% Correctness of a4q2;
• 10% Adherence to the specification;

• 10% Coding style, modularity and readability of the code (meaningful names, proper organization).
• 5% Try to write self-documenting code; that is, code which is readable with minimal amount of
comments.