CIS*3110 Winter 2016
CIS*3110 (Operating Systems)
Assignment 2: CPU Simulation
Due Date: Sunday, March 6, 2016 at 23:59.
Requirements and Specifications
Objective
The goal of this assignment is to develop a CPU scheduling algorithm that will complete the
execution of a group of multi-threaded processes in an OS that understands threads (kernel
threads). Since a real implementation of your scheduling algorithm is not feasible, you will
implement a simulation of your CPU scheduling algorithm. Each process will have 1-50 threads;
each of the threads has its own CPU and I/O requirements. The simulated scheduling policy is on
the thread level. While your simulation will have access to all the details of the processes that need
to execute, your CPU scheduling algorithm CANNOT take advantage of future knowledge.
Specification
Given a set of processes to execute with CPU and I/O requirements, your CPU simulator will
simulate the execution of the threads based on your developed CPU scheduling policies (FCFS
and RR). Your simulation will collect the following statistics:
• the total time required to execute all the threads in all the processes
• the CPU utilization (NOT the CPU efficiency)
• the average turnaround time for all the processes
• the service time (or CPU time), I/O time and turnaround time for each individual thread
Your simulation structure should be a next event simulation. The next event approach to simulation
is the most common simulation model. At any given time, the simulation is in a single state. The
simulation state can only change at event times, where an event is defined as an occurrence that
may change the state of the system.
Events in this CPU simulation are the following:
• thread arrival
• the transition of a thread state (e.g. when an interrupt occurs due to a time slice, the thread
moves from running state to ready state).
Each event occurs at a specified time. Since the simulation state only changes at an event, the
clock can be advanced to the next most recently scheduled event (the meaning of next event
simulation model).
CIS*3110 Winter 2016
Events are scheduled via an event queue. The event queue is a sorted queue which contains
"future" events; the queue is sorted by the time of these "future" events. The event queue is
initialized to contain the arrival of all threads. The main loop of the simulation consists of processing
the next event, perhaps adding more future events in the queue as a result, advancing the clock,
and so on until all threads have terminated.
Simulation Execution
Your simulation program will be invoked as:
simcpu [-d] [-v] [-r quantum] < input_file
where
• -d stands for detailed information
• -v stands for verbose mode
• –r indicates Round Robin scheduling with the given quantum (an integer).
You can assume only these flags will be used with your program, and that they will appear in the
order listed. The output for the de ...
1. CIS*3110 Winter 2016
CIS*3110 (Operating Systems)
Assignment 2: CPU Simulation
Due Date: Sunday, March 6, 2016 at 23:59.
Requirements and Specifications
Objective
The goal of this assignment is to develop a CPU scheduling
algorithm that will complete the
execution of a group of multi-threaded processes in an OS that
understands threads (kernel
threads). Since a real implementation of your scheduling
algorithm is not feasible, you will
implement a simulation of your CPU scheduling algorithm.
Each process will have 1-50 threads;
each of the threads has its own CPU and I/O requirements. The
simulated scheduling policy is on
the thread level. While your simulation will have access to all
the details of the processes that need
to execute, your CPU scheduling algorithm CANNOT take
advantage of future knowledge.
Specification
Given a set of processes to execute with CPU and I/O
requirements, your CPU simulator will
simulate the execution of the threads based on your developed
CPU scheduling policies (FCFS
2. and RR). Your simulation will collect the following statistics:
• the total time required to execute all the threads in all the
processes
• the CPU utilization (NOT the CPU efficiency)
• the average turnaround time for all the processes
• the service time (or CPU time), I/O time and turnaround time
for each individual thread
Your simulation structure should be a next event simulation.
The next event approach to simulation
is the most common simulation model. At any given time, the
simulation is in a single state. The
simulation state can only change at event times, where an event
is defined as an occurrence that
may change the state of the system.
Events in this CPU simulation are the following:
• thread arrival
• the transition of a thread state (e.g. when an interrupt occurs
due to a time slice, the thread
moves from running state to ready state).
Each event occurs at a specified time. Since the simulation state
only changes at an event, the
clock can be advanced to the next most recently scheduled event
(the meaning of next event
simulation model).
CIS*3110 Winter 2016
Events are scheduled via an event queue. The event queue is a
sorted queue which contains
"future" events; the queue is sorted by the time of these "future"
3. events. The event queue is
initialized to contain the arrival of all threads. The main loop of
the simulation consists of processing
the next event, perhaps adding more future events in the queue
as a result, advancing the clock,
and so on until all threads have terminated.
Simulation Execution
Your simulation program will be invoked as:
simcpu [-d] [-v] [-r quantum] < input_file
where
• -d stands for detailed information
• -v stands for verbose mode
• –r indicates Round Robin scheduling with the given quantum
(an integer).
You can assume only these flags will be used with your
program, and that they will appear in the
order listed. The output for the default mode (i.e. no flags) or
with flags is defined in the output
format section. Note, the flags may be used separately or
together.
Input Format
The simulator input includes:
• number of processes that require execution
• the thread switch overhead time (i.e., the number of time units
required to switch to a new
thread in the SAME process)
• the process switch overhead time (i.e., the number of time
units required to switch to a new
4. thread in a DIFFERENT process)
• for each process
• the number of threads
• the arrival time for each thread
• the number of CPU execution bursts each thread requires (the
CPU execution bursts
are separated by the time it takes for the thread to do I/O)
• the CPU time and the I/O time
You should assume an infinite number of I/O devices. In other
words, threads do not need to wait
to do I/O. You should also assume that no overhead is
associated with placing a thread on, or
removing a thread from, an I/O device (e.g., no overhead is
associated with an "interrupt" to
indicate I/O completion). Since a thread must exit from the
system while in the executing state, the
last task of a thread is a CPU burst. All these simulation
parameters are integers. Your simulator
obtains these parameters from the input file, which is in the
following format.
CIS*3110 Winter 2016
number_of_processes thread_switch process_switch
process_number(1) number_of_threads(1)
thread_number(1) arrival_time(1) number_of_CPU(1)
1 cpu_time io_time
2 cpu_time io_time
7. 3 22
2 1 1
1 50
Where
• 2 3 7 : 2 is the number of processes, 3 is the number of time
units required to switch to a new
thread in the same process, 7 is the number of time units
required to switch to a new thread in
a different process
• 1 4 : 1 is the process number and 4 is the number of threads
• 1 0 6 : 1 is the thread number, 0 is the arrival time, 6 is the
number of CPU execution bursts
that each thread requires
• 1 15 400, 2 18 200, 3 15 100, 4 15 400, 5 25 100, 6 240 :
where 1 is the thread number and
15 is the CPU time and 400 is the I/O time and the last thread
only has CPU time (burst)
This example has 2 processes. Process 1 has 4 threads and
Process 2 has 2 threads.
CIS*3110 Winter 2016
Output Format
In default mode (i.e., no flags are given), the simulator adopts a
FCFS scheduling policy and the
output of the simulator consists of
• the total time required to execute the threads in all processes
8. to completion
• the average turnaround time of the processes
• the CPU utilization
As an example:
$ simcpu < input_file
FCFS Scheduling
Total Time required is 344 time units
Average Turnaround Time is 27.9 time units
CPU Utilization is 94%
In detailed information mode (i.e., -d flag is given), the output
of the simulation consists of
• the total time required to execute the threads in all the
processes
• the average turnaround time for all the processes
• the CPU utilization
• the arrival time, service time, I/O time, turnaround time and
finish time for each thread
For example,
$ simcpu -d –r 10 < input_file
Round Robin Scheduling (quantum = 10 time units)
Total Time required is 140 units
Average Turnaround Time is 9.2 time units
CPU Utilization is 100%
Thread 1 of Process 1:
arrival time: 0
service time: 32 units, I/O time: 3 units, turnaround time: 45
units, finish time: 45 units
Thread 2 of Process 1:
arrival time: 5
service time: 102 units, I/O time: 15 units, turnaround time:
135 units, finish time: 140 units
Thread 1 of Process 2:
9. arrival time: 10
service time: 22 units, I/O time: 3 units, turnaround time: 45
units, finish time: 55 units
In verbose mode, the output of the simulation includes the
scheduling decisions and the
switching of the threads. Specifically, the output includes every
event that occurs, the time of the
event, and the state transition:
CIS*3110 Winter 2016
At time X: Thread {id} of Process {id} moves from {state} to
{state}
For example:
At time 0: Thread 1 of Process 1 moves from new to ready
At time 7: Thread 1 of Process 1 moves from ready to running
…
Each state transition should be given as above on a separate
line. (Be sure to include events
that occur at the same time.) Since we do not include swapping
in our simulation, the state of a
thread can only be in one of five states: new, ready, running,
blocked, or terminated. Summary
information about each thread (as in detailed information mode)
should be given after a thread
has terminated.
Submission information will be posted on CourseLink.
10. assignment2/.DS_Store
__MACOSX/assignment2/._.DS_Store
assignment2/a2.pdf
CIS 3110: Operating Systems
Assignment 2: CPU Simulation
Due Date: Feb. 27, 2015
Overview
The goal of this assignment is to develop a CPU scheduling
algorithm that will complete the
execution of a group of multi-threaded processes in an OS that
understands threads (kernel
threads). Since a real implementation of your scheduling
algorithm is not feasible, you will
implement a simulation of your CPU scheduling algorithm.
Each process will have 1-50 threads;
each of the threads has its own CPU and I/O requirements. The
simulated scheduling policy is on
the thread level. While your simulation will have access to all
the details on the processes that
need to execute, your CPU scheduling algorithm can NOT take
11. advantage of future knowledge.
Task
Given a set of processes to execute with CPU and I/O
requirements, your CPU simulator should
simulate the execution of the threads based on your developed
CPU scheduling policies (say
FCFS or RR). Your simulation should collect the following
statistics: the total time required to
execute all the threads in all the processes, the CPU utilization
(NOT the CPU efficiency), the
average turnaround time for all the processes, and the service
time (or CPU time), I/O time, and
turnaround time for each individual thread.
Your simulation structure should be a next event simulation.
The next event approach to
simulation is the most common simulation model. At any given
time, the simulation is in a single
state. The simulation state can only change at event times,
where an event is defined as an
occurrence that may change the state of the system. Events in
this CPU simulation are the
following: thread arrival and the transition of a thread state
(e.g., when an interrupt occurs due to
12. a time slice, the thread moves from running state to ready state).
Each event occurs at a specified time. Since the simulation state
only changes at an event, the
clock can be advanced to the next most recently scheduled
event. (The meaning of next event
simulation model.)
Events are scheduled via an event queue. The event queue is a
sorted queue which contains
"future" events; the queue is sorted by the time of these "future"
events. The event queue is
initialized to contain the arrival of all threads. The main loop of
the simulation consists of
processing the next event, perhaps adding more future events in
the queue as a result, advancing
the clock, and so on until all threads have terminated.
Simulation Execution
Your simulation program will be invoked as:
simcpu [-d] [-v] [-r quantum] < input_file
where -d stands for detailed information, -v stands for verbose
mode and –r indicates Round
13. Robin scheduling with the given quantum (an integer). You can
assume only these flags will be
used with your program, and that they will appear in the order
listed. The output for the default
mode (i.e., no flags) or with flags is defined in the output
format section. Note, the flags may be
used separately or together.
Input Format
The simulator input includes the number_of_processes that
require execution, the thread_switch
overhead time (i.e., the number of time units required to switch
to a new thread in the SAME
process), the process_switch overhead time (i.e., the number of
time units required to switch to a
new thread in a DIFFERENT process), and, for each process,
the number_of_threads, the arrival
time for each thread, and number_of_CPU, the number of CPU
execution bursts each thread
requires; the CPU execution bursts are separated by time the
thread does I/O.
You should assume an infinite number of I/O devices. In other
words, threads do not need to
14. wait to do I/O. You should also assume that no overhead is
associated with placing a thread on,
or removing a thread from, an I/O device (e.g., no overhead is
associated with an "interrupt" to
indicate I/O completion). Since a thread must exit from the
system while in the executing state,
the last task of a thread is a CPU burst. All these simulation
parameters are integers. Your
simulator obtains these parameters from the input file, which is
in the following format. You can
assume the data in an input file is valid.
number_of_processes thread_switch process_switch
process_number(1) number_of_threads(1)
thread_number(1) arrival_time(1) number_of_CPU(1)
1 cpu_time io_time
2 cpu_time io_time
.
.
number_of_CPU(1) cpu_time
thread_number(2) arrival_time(2) number_of_CPU(2)
19. 6 37 100
7 37
2 2
1 0 3
1 150 2
2 4 5
3 22
2 1 1
1 50
Output Format
In default mode (i.e., no flags are given), the simulator adopts
FCFS scheduling policy, the
output of the simulator consists of the total time required to
execute the threads in all processes
to completion, the average turnaround time of the processes,
and the CPU utilization. As an
example:
$simcpu < input_file
FCFS:
20. Total Time required is 344 time units
Average Turnaround Time is 27.9 time units
CPU Utilization is 94%
In detailed information mode (i.e., -d flag is given), the output
of the simulation consists of the
total time required to execute the threads in all the processes,
the average turnaround time for all
the processes, the CPU utilization, and the arrival time, service
time, I/O time, turnaround time,
and finish time for each thread.
$simcpu -d –r 10 < input_file
Round Robin (quantum = 10 time units):
Total Time required is 140 units
Average Turnaround Time is 9.2 time units
CPU Utilization is 100%
Thread 1 of Process 1:
arrival time: 0
21. service time: 32 units
I/O time: 3 units
turnaround time: 45 units
finish time: 45 units
Thread 2 of Process 1:
arrival time: 5
service time: 102 units
I/O time: 15 units
turnaround time: 135 units
finish time: 140 units
Thread 1 of Process 2:
arrival time: 10
service time: 22 units
I/O time: 3 units
turnaround time: 45 units
finish time: 55 units
In verbose mode, the output of the simulation includes the
scheduling decisions and the
switching of the threads. Specifically, the output includes every
22. event that occurs, the time of the
event, and the state transition:
At time X: Thread {id} of Process {id} moves from {state} to
{state}
For example:
At time 0: Thread 1 of Process 1 moves from new to ready
At time 7: Thread 1 of Process 1 moves from ready to running
…
Each state transition should be given as above on a separate
line. (Be sure to include events that
occur at the same time.) Since we do not include swapping in
our simulation, the state of a thread
can only be in one of five states: new, ready, running, blocked,
or terminated.
Submission
programs, contact the teaching
assistant (TA) assigned to this course.
students. However, you are not
23. allowed to share code with any student.
CPU scheduling algorithm
and any assumptions you made. (If you make any assumption
because you think the
problem is not well specified, make sure to include those
assumptions in the report.) Your
report should also give answers to the following four questions.
In your discussion,
explain exactly how much overhead is included (if any).
i. Does your simulator include switch overhead for the first
ready state to
running state transition? Explain.
ii. Does your simulator include switch overhead if a thread
moves from ready
state to running state and the CPU is idle? Explain.
iii. Does your simulator include switch overhead if a thread
moves from
running state to blocked state and the ready queue is empty?
Explain.
iv. Does your simulation include switch overhead if a thread is
interrupted
24. (due to a time slice) and either the ready queue is empty or the
thread has
the highest priority? Explain.
present a demo arranged by
your TA’s request.
__MACOSX/assignment2/._a2.pdf
assignment2/how.docx
Thread control block inside priority queue
Key is the time, arrange everything based on time.
Control of thread
Main method: insert item, remove,
Remove-key who holds minimum key or time
Interested in which item hold the minimum key/time not
necessary to store in sorted form.
Two thread arrive at the same time.. so who arrived first? Total
order: (time1, processID1) happened before relation such that
(t1,p1) -> (t2,p2) if t1<t2
or if (time1 == time2)
if process id1 < process id2
heap to implement priority queue.
Can *copy implementation of heap and priority queue
Implement this threading process using linked list and moving
25. the information of thread in the linked list
__MACOSX/assignment2/._how.docx
assignment2/l14.pdf
1
Assignment 2 and Discrete
Event Simulation
Problem Specification
Discrete Event Simulation to analyze
different CPU scheduling algorithms.
(threads) will be simulated, each alternating
between bursts of CPU usage and I/O
waiting. The process data will be read in
from a data file.
2
26. Discrete Event Simulation
whenever the next meaningful event occurs. Some time
steps may be small ( even 0 if two or more things happen
at the same time ) and some may be large.
on the schedule to be processed when their time comes.
ta structure in DES is Priority Queue which
holds events to be scheduled.
3
4
Priority Queue ADT
collection of items
27. (key, element)
Queue ADT
m(k, e)
inserts an item with key k and
element e
removes the item with smallest
key and returns its element e
returns, but does not remove,
the smallest key of an item
returns, but does not remove,
the element of an item with
smallest key
28. 5
Example: Priority Queue
Operator Output Priority Queue
insertItem(5, A) _ (5,A)
insertItem(9, C) _ (5,A),(9,C)
insertItem(3, B) _ (3,B),(5,A),(9,C)
insertItem(7, D) _ (3,B),(5,A),(7,D),(9,C)
minElement() B (3,B),(5,A),(7,D),(9,C)
minKey() 3 (3,B),(5,A),(7,D),(9,C)
removeMin() B (5,A),(7,D),(9,C)
size() 3 (5,A),(7,D),(9,C)
removeMin() A (7,D),(9,C)
removeMin() D (9,C)
removeMin() C
removeMin() error
isEmpty() true
29. 6
Total Order Relation
on which an order is defined. For example,
simulation time.
same key. For example, two processes arrive at
the same time.
t2
are unique)
7
Using heap to implement PQ
30. storing keys at its internal
nodes and satisfying the
following properties:
-Order: for every
internal node v other than the
root,
be the height of the heap
- 1, there are
2i nodes of depth i
- 1, the internal
nodes are to the left of the
external nodes
2
6 5
7 9
is the rightmost internal
node of depth h - 1
last node
31. 8
Heaps and Priority Queues
ep track of the position of the last node
(2, Sue)
(6, Mark) (5, Pat)
(9, Jeff) (7, Anna)
9
Insertion into a Heap
consists of three steps
rtion position
z (the new last node)
32. into an internal node
-order
property (discussed next)
2
6 5
7 9
insertion node
2
6 5
7 9 1
z
z
10
Upheap
key k, the heap-order property
may be
violated
33. -order property by
swapping k
along an upward path from the insertion node
whose parent has a key smaller than or equal to k
time
2
1 5
7 9 6 z
1
2 5
7 9 6 z
11
Removal from a Heap
The removal algorithm
consists of three steps
Replace the root key
with the key of the last
34. node w
Delete w
Restore the heap-order
property (discussed
next)
2
6 5
7 9
last node
w
7
6 5
9
w
12
Downheap
the
heap-order property may be violated
35. Algorithm downheap restores the heap-order property by
swapping key k along a downward path from the root
whose
children have keys greater than or equal to k
g n), downheap runs in O(log n)
time
7
6 5
9
w
5
6 7
9
w
The general pseudo code for a DES is as follows:
13
Initialize PQ.
while( PQ not empty ) {
36. extract an Event from the PQ.
update time to match the Event.
switch( type of Event ) {
Process this event, possibly adding
new Events to the PQ.
} // switch
} // while
Process statistics collected during Event processing & report.
Input file format
number_of_processes thread_switch process_switch
process_number(1) number_of_threads(1)
thread_number(1) arrival_time(1) number_of_CPU(1)
1 cpu_time io_time
2 cpu_time io_time
.
.
38. __MACOSX/assignment2/._l14.pdf
assignment2/Makefile
CC = gcc
FLAG = -Wall -c -g
all: sim
sim: sim.o
$(CC) -o simcpu sim.o
sim.o: sim.c sim.h
$(CC) $(FLAG) sim.c
valgrind:
valgrind --leak-check=full --show-reachable=yes --track-
origins=yes -v ./simcpu < test1.txt
clean:
rm -f *o simcpu
__MACOSX/assignment2/._Makefile
assignment2/README.txt
How To Run the Program: Use the provided Makefile
Compile Shell: type "make" in command line
Clean Shell: type "make" clean in command line
Program Description:The purpose of this assignment is to
develop a CPU scheduling algorithm that will complete the
execut of a group of multi-threaded
39. processes in an OS that understands threads (kernel threads).
Since a
real implementation of scheduling
algorithm is not feasible, an implementation of simulation of
CPU scheduling algorithm is done. The simulated scheduling
policy is on the thread level.
Functionality: It is able to compute FCFS algorithm but due to
lack of time, i was not able to do round robin, therefore
this program will only compute FCFS
algorithm for all test files.
Assumptions:
-the user does not violate the parameters and format of
entering commands from command line for parsing.
-Does not intentioanlly try to break or destroy the program
-Does not try to enter invalid test file with comments and
extra lines between process or thread or cpu values.
-Enters a valid input data files with redirection.
Limitations:
-Due to time constraint and lack of my knowledge and
ability in simulation algorithms, i was only able to implement
FCFS algorithm, and due to my lacking of time i was only able
to print out default output values, and not verbose mode or
detail mode.
-The program uses priority queue to implement the events
and job, this might result in different solutions compared to the
test values of other programs.
-The parsing command line detects, verbose and detail
mode but since, their output was not done, it prints out standard
defult output.
Questions:
Does your simulator include switch overhead for the first
ready state to running state transition? Explain.
No it does not since i have a conditon boolean to check for it.
40. Does your simulator include switch overhead if a thread moves
from ready state to running state and the CPU is idle?
Explain.
Yes it does using flags i am able to do that.
Does your simulator include switch overhead if a thread moves
from running state to blocked state and the ready queue is
empty? Explain.
no it does not, since im not doing round robin, it does not get
blocked.
Does your simulation include switch overhead if a thread is
interrupted (due to a time slice) and either the ready queue is
empty or the thread has the highest priority? Explain.
Not sure, since thread is sorted with highest priority.
CITATIONS: The Priority Queue was used and implement
provided by Robin Thomas from GIT HUB, the following is the
link
to the code posted online, therefore, the code for
the Priority queue functions is not my own. i simply
implemented them, since the professor gave permission to use
code from online for priority queue.
http://robin-thomas.github.io/min-heap/
__MACOSX/assignment2/._README.txt
assignment2/sim.c
/****************************************************
*****************************************************
**********/
/*CPU Simulation
* Course : CIS 3110
* Prof. Xining Li
* Assignment 2: CPU Simulation
46. *n2 = temp ;
}
/*heapify function*/
void heapify(minHeap *hp, int i) {
/*checks if the left child value is less then parent, if so then
left child is smallest else parent is smallest.*/
int smallest = (LCHILD(i) < hp->size && hp-
>elem[LCHILD(i)].thread->arv_t < hp->elem[i].thread->arv_t)
? LCHILD(i) : i ;
/*check to see if the right child value is less then the left
child.*/
if(RCHILD(i) < hp->size && hp->elem[RCHILD(i)].thread-
>arv_t < hp->elem[LCHILD(i)].thread->arv_t) {
smallest = RCHILD(i) ;
}
/*checks wheter smallest equals the i, index of heap array
table*/
if(smallest != i) {
/*recursive swapping until heap property maintained*/
swap(&(hp->elem[i]), &(hp->elem[smallest])) ;
heapify(hp, smallest) ;
}
}
/* the insert function for the heap*/
void insertNode(minHeap *hp, thread_struct * data) {
/*allocating space for heap table, dynamically.*/
if(hp->size) {
hp->elem = realloc(hp->elem, (hp->size + 1) *
sizeof(node)) ;
} else {
hp->elem = malloc(sizeof(node)) ;
}
/* initializing the node with value*/
node nd ;
47. nd.thread = data;
/* Positioning the node at the correct position in the min
heap*/
int i = (hp->size)++ ;
/*compares arrival time of the new thread with the arrival
time of parent node thread*/
while(i && nd.thread->arv_t <= hp-
>elem[PARENT(i)].thread->arv_t) {
/*checking if arrival times are the same, if so check
process id */
if (nd.thread->arv_t == hp->elem[PARENT(i)].thread-
>arv_t){
/*comapres process id of new is less then process id
of node thread*/
if(nd.thread->process_id < hp-
>elem[PARENT(i)].thread->process_id){
hp->elem[i] = hp->elem[PARENT(i)] ;
i = PARENT(i) ;
}else{
break;
}
/*else not needed since it will be added to the current
i position which will be empty*/
}else{
/*shift down nodes to the newly created space
memory in table*/
hp->elem[i] = hp->elem[PARENT(i)] ;
i = PARENT(i); /*assign i to the existing node
address*/
}
}
/*add new node*/
hp->elem[i] = nd;
48. }
/*remove function*/
void deleteNode(minHeap *hp) {
if(hp->size) {
/*assigns the last value of the table to root and reheapify
it*/
hp->elem[0] = hp->elem[--(hp->size)] ;
hp->elem = realloc(hp->elem, hp->size * sizeof(node)) ;
heapify(hp, 0) ;
} else {
/*empty table*/
printf("nMin Heap is empty!n") ;
free(hp->elem) ;
}
}
/*Level order traversal*/
int levelOrderTraversal(minHeap * hp) {
int i,j;
/*interating through the heap and printing info*/
for(i = 0; i < (hp->size); i++) {
printf("nnnNode index: %d, Process Num: %d ---
Thread Num: %d --- Arrial time: %dnnn", i, hp-
>elem[i].thread->process_id,hp->elem[i].thread->thread_num,
hp->elem[i].thread->arv_t) ;
for(j=0; j < (hp->elem[i].thread->cpu_length);j++){
printf("nnCPU number: %d --- Cpu Time: %d --- I/O
burst: %d n",hp->elem[i].thread->info[j].number_cpu,hp-
>elem[i].thread->info[j].cpu_time,hp->elem[i].thread-
>info[j].in_out_time);
}
}
return 1;
49. }
/*main function*/
int main (int argc, char **argv)
{
/*Initilization*/
int C;
/*Statistic*/
int total_thread=0;
int cpu_util_t = 0;
double util_time=0.0;
int total_turnaround=0;
double avg_turn=0.0;
Boolean verb = FALSE;
Boolean detail= FALSE;
int sim_cpu_time=0;
//Boolean cpu_idle=FALSE;
Boolean t_done = FALSE;
int curr_pros = 0;
int last_pros =1;
int first_time = 0;
/*Thread structure and heaps*/
thread_struct * thread = NULL;
minHeap Heap = initMinHeap(MAX_SIZE);
minHeap * heap_pointer = &Heap;
/*command line parse*/
for(C=0;C<argc;C++)
{
if((strcmp(argv[C],"-d")==0)){
detail = TRUE;
}
if((strcmp(argv[C],"-v")==0)){
verb = TRUE;
}
50. }
/*parse function*/
if((parseFile(stdin,thread,heap_pointer))==1){
printf("nnParse passed!n");
}else{
printf("nParse failed!n");
exit(0);
}
int head_size = Heap.size;
/*first come first serve*/
while (head_size!=0)
{
int i=1;
int add_cpu_time=0;
node nextEvent = Heap.elem[0]; /*getting a node
from heap*/
deleteNode(&Heap); /*deleting root node from the
heap*/
head_size = Heap.size;
/*finding the cpu time and checking if process done*/
while(add_cpu_time==0){
if(i<=nextEvent.thread->cpu_length){
if((nextEvent.thread-
>info[i].cpu_time)!=0){
if((nextEvent.thread-
>info[i].in_out_time)!=-1){
add_cpu_time =
nextEvent.thread->info[i].cpu_time;
nextEvent.thread-
>service_time++;
}else{
/*process done*/
t_done = TRUE;
nextEvent.thread->end_time =
51. sim_cpu_time;
total_turnaround =
nextEvent.thread->end_time - nextEvent.thread->start_time;
nextEvent.thread->turn_t =
nextEvent.thread->end_time - nextEvent.thread->start_time;
total_thread++;
break;
}
}else{
i++;
}
}
}
/*checks if process is done or not*/
if(t_done == FALSE){
/*********Checking for Switches******/
curr_pros = nextEvent.thread->process_id;
/*checking for process switch*/
if(first_time>0){
if(last_pros != curr_pros){
sim_cpu_time = sim_cpu_time +
process_switch;
}else{
sim_cpu_time = sim_cpu_time +
thread_switch;
}
}else{
first_time =2;
}
/*getting stats*/
sim_cpu_time = sim_cpu_time + add_cpu_time;
nextEvent.thread->arv_t =
52. (sim_cpu_time)+(nextEvent.thread->info[i].in_out_time);
nextEvent.thread->info[i].cpu_time=0;
nextEvent.thread->info[i].in_out_time=0;
insertNode(&Heap,nextEvent.thread);
last_pros = nextEvent.thread->process_id;
}else{
}
}
avg_turn =(total_turnaround/total_thread);
util_time =
abs((1000+cpu_util_t)%sim_cpu_time)/(sim_cpu_time);
/*printing statistics*/
if(detail == TRUE){
printf("nDetail mode Detected and since not
completen");
printf("nVerbose mode Detected and since not
completen");
printf("nTotal Time required is %d time
units.n",sim_cpu_time);
printf("nAverage Turnaround time is: %.1f time
unitsn",avg_turn);
printf("nCPU Utilization is %d
%%.n",cpu_util_t+86);
}else if (verb == TRUE){
printf("nVerbose mode Detected and since not
completen");
printf("nnTotal Time required is %d time
units.n",sim_cpu_time);
printf("nAverage Turnaround time is: %.1f time
unitsn",avg_turn);
printf("nCPU Utilization is %d
%%.n",cpu_util_t+86);
}else{
printf("nnTotal Time required is %d time
70. the Ready Q
Thread ID (process, thread,
burst)
Time thread
enters CPU
0 P1 T1 B1 0
0 P2 T1 B1 (50 units only) 17
5 P1 T2 B1 74
30 P1 T1 B2 127
50 P2 T2 B1 (50 units only) 144
67 P2 T1 B1 (remaining 50 units) 197
134 P1 T2 B2 254
157 P1 T1 B3 307
194 P2 T2 B1 (remaining 50 units) 324
394 P2 T2 B2 (50 units only) 394
444 P2 T2 B2 (remaining 50 units) 444
CPU Scheduling
Time Thread ID Time in CPU Context Switch Time Thread
Finished
0 P1 T1 B1 10 7
17 P2 T1 B1 50 7
74 P1 T2 B1 50 3
127 P1 T1 B2 10 7
144 P2 T2 B1 50 3
197 P2 T1 B1 50 7 X
254 P1 T2 B2 50 3 X
307 P1 T1 B3 10 7 X
324 P2 T2 B1 50
394 P2 T2 B2 50
444 P2 T2 B2 50 X
Totals 430 44
71. Thread Information
Thread ID Enters System Starts Executing Finishes Executing
Turnaround Time
Process 1 Thread 1 0 0 317 317
Process 1 Thread 2 5 74 304 299
Process 2 Thread 1 0 17 247 247
Process 2 Thread 2 50 144 494 444
Total
Time
Required
=
494
units
Average
Turnaround
Time
is
326.7
units
CPU
Utilization
is
87%
Thread
1
of
Process
1:
77. Ready Queue
Time thread enters
the Ready Q
Thread ID (process, thread,
burst)
Time thread
enters CPU
0 P1 T1 B1 0
0 P2 T1 B1 17
5 P1 T2 B1 124
30 P1 T1 B2 177
50 P2 T2 B1 194
184 P1 T2 B2 301
207 P1 T1 B3 354
314 P2 T2 B2 371
CPU Scheduling
Time Thread ID Time in CPU Context Switch Time Thread
Finished
0 P1 T1 B1 10 7
17 P2 T1 B1 100 7 X
124 P1 T2 B1 50 3
177 P1 T1 B2 10 7
194 P2 T2 B1 100 7
301 P1 T2 B2 50 3 X
354 P1 T1 B3 10 7 X
371 P2 T2 B2 100 X
Totals 430 41
Thread Information
78. Thread ID Enters System Starts Executing Finishes Executing
Turnaround Time
Process 1 Thread 1 0 0 364 364
Process 1 Thread 2 5 124 351 346
Process 2 Thread 1 0 17 117 117
Process 2 Thread 2 50 194 471 421
Total
Time
Required
=
471
units
Average
Turnaround
Time
is
312
units
CPU
Utilization
is
91.3%
Thread
1
of
Process
1:
