Download Final Report

Operating
Systems Simulator
Jessica Craddock
Kelvin Whyms
CPSC 410
Executive Summary
The large system programming assignment that we selected was an Operating
System Simulator. The Operating System Simulator demonstrated what takes place
during scheduling, deadlock detection, and memory management. Visually walking
through every step in the process and showing all the details helps to reinforce the topics
that were discussed in the class room related to the same topics.
The additional graphical user interface that was developed to allow the individual
applications to be executed from one centralized location helped to simplify the program
and make it easier to work with. The user was not required to interact directly with the
console but could just change a few numbers in one line of code.
System Selection
The large programming project that we decided to focus on was the operating
system simulator. The simulator allowed us to further investigate the topics that we
discussed earlier in the semester and helped to reinforce the topics. Selecting this
program also helped us gain a better understanding of exactly what was going on in the
operating system. We gained a better appreciation for the work the operating system
does and the programmers that develop operating systems.
By looking over the code required for the few topics that we selected we began to
understand just how much work and effort went into programming an operating system.
The amount of work that must go into generating that many lines of code and having
them work with only a few minuscule flaws is amazing. Windows itself has gone from 6
million lines of code with Windows 3.1 to 50 million lines of code with the new
Windows Vista. The size of the program is staggering.
When we found the program it was already written but when we went and rewrote
some of the code and changed the inputs we had to understand how the code worked. It
forced us to understand exactly what was going on. We still would have understood the
code but we were able to get an even better understanding when we were forced to
manipulate the code.
As computer science majors we are going to see many different operating systems
in our lifetime. Every time we interact with a computer we are interfacing with the
operating system. To be able to understand how a few simple principles of a generic
operating system work we can better understand the past, current and future operating
systems that we are bound to face at some point in our life time and career.
System Analysis
During the initial analysis of the programs we noticed the all the programs
required input files and all inputs must be entered into the console when executing the
code. The input files tell the programs what they need to be done, telling the program at
what time and how long to run the processes.
The graphical user interfaces that were pre designed for the deadlock detection
and memory management allow the user to step through the program and each time unit
allows the user to see what has changed and see the exact characteristics of the processes.
The scheduling simulator does not print anything to console except working and
complete. The result and calculations about the time it takes to complete and the number
of times it was blocked are all recorded in a summary text file.
The file system simulator imitates a UNIX file system but requires that the user
execute all the individual classes from the console and input all the information.
The deadlock detection simulator requires input file that describe the processes
and will not run if it can not find those individual files.
The memory management has input files that set up all the individual memory
locations with the information and another file specifies how the pages are to be replaced,
read and written.
It would have been nicer if the operating system simulator had included
simulations on other principles such as semaphores and threads. Also would have been
more course related if it had included both Dekker’s algorithm for deadlock detection as
well as Banker’s algorithm. Disk scheduling algorithms would also have been a nice
addition to the simulator to help students better understand the inter workings of the
operating system. The operating system principles that are incorporated into the program
clearly work well.
System Design
The system that we designed to combine the classes was a graphical user
interfaces that allows the user to hit a button and runs the application connected to that
button.
All the previous classes were separated into packages based on what project they
related to. Then package declarations were added to each individual java file in the
package folder. In the main class, the Simulator class, which preformed all the functions
the packages, was imported and Objects of the main classes in each package were made.
No constructor needed to be created in the classes because java automatically assumes if
no constructor is specified in the class that we want to use the default constructor. The
buttons were designed so that the action Preformed methods of each button would act like
the input line in the console. The parameters were setup in String arrays and passed to
main method.
We designed the interface to be simple and straight forward. Multiple instances
of each program can be run at the same time and all four of the programs can be run at
the same time as well.
Operating System Principles and Significance
The scheduling simulator illustrates the behavior of scheduling algorithms against
a simulated mix of process loads. The user can specify the number of processes, the mean
and standard deviation for compute time and I/O blocking time for each process, and the
duration of the simulation. At the end of the simulation a statistical summary is presented.
Students may also be asked to write their own scheduling algorithms to be used with
process loads defined by the instructor.
The deadlock simulator illustrates multiple processes competing for one or more
resources to investigate the nature and causes of deadlock conditions and how they can be
avoided, detected, and resolved. The simulator includes a graphical user interface that
allows the student to step through the "programs" being concurrently "executed" by each
of the processes and see which processes are blocked by which resources. A typical
student lab exercise might require students to write simple "programs" for the simulator
to investigate different kinds of resource contention conditions. More advanced students
might write a deadlock manager (in Java) based on the template provided, and test it
using "programs" of their own design.
The memory management simulator illustrates page fault behavior in a paged
virtual memory system. The program reads the initial state of the page table and a
sequence of virtual memory instructions and writes a trace log indicating the effect of
each instruction. It includes a graphical user interface so that students can observe page
replacement algorithms at work. Students may be asked to implement a particular page
replacement algorithm which the instructor can test by comparing the output from the
student's algorithm to that produced by a working implementation.
The file system simulator shows the inner workings of a UNIX V7 file system.
The simulator reads or creates a file which represents the disk image, and keeps track of
allocated and free blocks using a bit map. A typical exercise might be for students to
write a program (in Java) which invokes various simulated operating system calls against
a well-known disk image provided by the instructor. Students may also be asked to
implement indirect blocks, list-based free block management, or write a utility (like fsck)
to check and repair the file system.
These principles are significant because they clearly illustrate the topics that were
covered during this semester in our lectures. The memory management shows how
virtual memory is used to store the pages in main memory. Memory Management uses
First Come First Serve to determine which page to replace. Scheduling is Nonpreemptive and uses First Come First Serve to schedule processes.
Problems Encountered and Solutions
The scheduling simulator and memory management allow for the user to go
through and write different replacement algorithms. Both memory management and
scheduling are written based on the first come first serve. Additionally the user could
implement more preemptive methods rather than non preemptive methods. Possibly
implementations include least recently used, round robin, feedback, shortest process next,
shortest remaining time, or highest response ratio next.
Since we used previously written code we had to take time and understand how
the different classes worked together. Also we had to fix the set up. The author had the
code written in one way but when we went to work with the code in Net beans it would
not work due to the fact that the classes were importing classes but it was not needed in
our current implementation.
The files that were needed to set up the classes initially were not being recognized
and we were receiving errors that the file did not exist. Once we actually specified the
location of the actual file the program would work. The java interpreter also interpreted
the backslash in the file path as an escape character and we had to enter ever backslash in
a file path twice to make sure java was not interpreting them as escape characters.
Methodology
To fix some of the problems that we encounter we needed to comment out
imports that were not necessary since the classes were already in the project folder. In
order for us to understand how the programs worked we experimented with the data
inputs to determine what and how the output was changing. We were getting errors
related to the location of the files especially with the inputs for the programs. To fix this
we just changed where the program was looking for the files by specifying the exact file
path of the file on my computer. To create the graphical user interface we used the
integrated graphical user interface builder that is included with net beans. This allowed
up to place the buttons exactly where we wanted and wrote all the code necessary to
make them function but did require use to add the additional handling code in the buttons
individual action preformed methods.
References
Ontko, Ray and Alexander Reeder. Modern Operating Systems Simulators. 19 Nov.
2001. 2 Dec. 2007. <http://www.ontko.com/moss/>
Stalling, William. Operating Systems-Internal and Design Principles,. 5th ed. Prentice
Hall, 2005.
Tanenbaum, Andrew. Modern Operating System. 2nd ed. Prentice Hall, 2001.
Zhang, Ming. CPSC 410 Class Lectures. 28 Aug. – 20 Nov. 2007.
Wikipedia. 29 Nov. 2007. <www.wikipedia.org>