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 Non-preemptive 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. <
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. <