$29
Project #2 OS Simulator Solution
Introduction
This set of programming assignments is designed to materialize all of the major operating systems concepts in the CS 446/646 course by allowing you to make design decisions during development of an operating system. These assignments will increase your understanding of operating systems and incorporate common aspects of industry and/or advanced academia.
Over the course of the semester, you will complete one introductory assignment and four simulation assignments. After the completion of the fourth simulation assignment, you will have simulated the core components of a modern day operating system. Each of the assignments build tremendously upon the previous assignment, thus it is advantageous for you to design each assignment with all future assignments in mind. This will signi cantly reduce your workload in the long run.
This document may change throughout the semester and suggestions may be made for any changes one week prior to the assignment due date. This is however at the instructor's discretion.
All of the simulation assignments must be completed using C or C++. All programs require the use of a make le. ALL PROGRAMS MUST RUN AND COMPILE IN THE ECC, OTHERWISE YOUR GRADE WILL RESULT IN A ZERO
1
Simulator Description
2.1 Expectations
A rubric will be provided for each program. In addition to the rubric, the following will be expected of each program throughout the simulation assignments:
since you will have an overview of all of the programs, it will be worth your time to consider the subsequent phases as you develop the rst program(s); if you have an overlying strategy from the beginning, extending each program will not be di cult
you may work with any number of fellow students to develop your program design, related data structures, algorithmic actions, and so on for each phase. If you do, you must note which students with whom you worked in your upload text on WebCampus; this is for your protection
that said, once you begin coding each phase, you may not discuss, or work, with anyone on your programming, strategy(s), debugging, and so on; it will behoove you to make sure you have a high-quality design developed prior to beginning your coding process
all programs must be eminently readable, meaning any reasonably competent programmer should be able to sit down, look at your code, and know how it works in a few minutes. This does not mean a large number of comments are necessary; your code itself should read clearly. You are also required to follow a documentation format in your code. If you would like an example on documentation, search "code documentation" in a search engine. You will be graded on the readability of your code and di culty in reading your code may result in a reduced grade
the program must demonstrate all the software development practices expected of a 400- (or 600-) level course. For example, all potential le failures must be resolved elegantly, any screen presentation must be of high quality, any data structures or management must demonstrate high quality, supporting actions and components must demonstrate e ective modularity with the use of functions, and so on. This means your code should be tested for failure and handled accordingly, including informing the user of the errors encountered in your simulator
you may use any I/O libraries or classes as needed, but any other classes must be created by you. In addition, you may use POSIX/pthread operations to manage your I/O operations but you may not use previously created threads such as timer threads (e.g., sleep, usleep, etc.). You may use the C standard template library and C standard string library. Additionally, you are free to use basic error libraries but the errors must be handled by you
for each programming assignment, each student will upload the program les through WebCampus. The le for each student must be tarred and zipped in Linux as speci ed below, and must be able to be unzipped on any of the ECC computers include any and all les necessary for the operation of the program. Any extraneous les such as unnecessary library or data les will be cause for credit reduction. The format for submission is Sim0X <LastNameFirstName.tar.gz where X represents the speci c project number, or as an example, Sim01 SmithJohn.tar.gz
all programs must run on the computers in the ECC with no errors or warnings. To remotely access the ECC (if you wish to test your programs) you can SSH to the ecc, copy your les, and run your les. Instructions for how to do this are listed at: https://source2.cse.unr.edu/w/cse/student_ resources/
2.2 Meta-Data
All assignments will use meta-data to house the information required to run each simulation. The meta acts as the set of instructions for your simulation to run on. The meta-data codes are as follows:
S - Operating System, used with begin and finish
2
A - Program Application, used with begin and finish P - Process, used with run
I - used with Input operation descriptors such as hard drive, keyboard, scanner
O - used with Output operation descriptors such as hard drive, monitor, projector M - Memory, used with block, allocate
The meta-data descriptors are as follows:
begin, finish, hard drive, keyboard, scanner, monitor, run, allocate, projector, block
The meta-data will always follow the format:
<META DATA CODE(<META DATA DESCRIPTOR)<NUMBER OF CYCLES
For example, an input keyboard operation that runs for 13 cycles would look like the following:
I(keyboard)13
Below is an example meta-data le:
Start Program Meta-Data Code:
S{begin}0; A{begin}0; P{run}11; P{run}9; P{run}12;
P{run}9; P{run}11; P({run}8; P{run}14; P{run}14; P{run}12;
4 P{run}12; P{run}6; P{run}8; P{run}9; P{run}6; P{run}14;
5 P{run}15; P{run}12; P{run}9; P{run}6; P{run}5; A{finish}0;
6 A{begin}0; P{run}6; P{run}6; P{run}9; P{run}11; P{run}13;
7 P{run}14; P{run}5; P{run}7; P{run}14; P{run}15; P{run}7;
8 P{run}5; P{run}14; P{run}15; P{run}14; P{run}7; P{run}14;
9 P{run}13; P{run}8; P{run}7; A{finish}0; A{begin}0; P{run}6;
P{run}10; P{run}13; P{run}9; P{run}15; P{run}6; P{run}13;
P{run}11; P{run}5; P{run}6; P{run}7; P{run}12; P{run}11;
P{run}6; P{run}8; P{run}10; P{run}5; P{run}8; P{run}9; P{run}7;
A{finish}0; S{finish}0.
End Program Meta-Data Code.
2.3 Con guration
Each assignment will use a con guration le to set up the OS simulation for use. This will specify the various cycle times associated with each computer component, memory, and any other necessary informa-tion required to run the simulation correctly. All cycle times are speci ed in milliseconds. For example, if the hard drive cycle time is 50 ms/cycle and you must run for 5 cycles, the hard drive must run for 250 ms. Log File Path is the name of the new le which will display the output. These will be used by a timer to accurately display timestamps for each OS operation. You must use an onboard clock interface of some kind to manage this, and the precision must be to the microsecond level. The con guration will need to be read in prior to running any processes. The con guration le will be key to setting the constraints under which your simulation will run.
Below is an example con guration le:
Start Simulator Configuration File
2 Version/Phase: 2.0
3 File Path: Test_2e.mdf
4 Projector cycle time {msec}: 25
3
Processor cycle time {msec}: 10
6 Keyboard cycle time {msec}: 50
7 Monitor display time {msec}: 20
8 Scanner cycle time {msec}: 10
9 Hard drive cycle time {msec}: 15
Log: Log to Both
Log File Path: logfile_1.lgf
End Simulator Configuration File
2.4 Running the Simulator
When running the simulator you will be required to input a single con guration le (extension .conf). You will run the simulator from the command line similar to the following:
./sim0X config 1.conf
The name of the assignment must be the simulator number. Many con guration les should be used to test your program, which you may modify for testing purposes as you see t.
2.5 Turning in Assignments
All assignments will be turned into WebCampus. You must submit a zipped .tar.gz archive as speci ed above. Inside the archive there should only be the les required to run the simulator (e.g., all source les, all header les). No resource les are allowed. Late assignments will not be accepted.
Assignment 1
3.1 Description
Assignment 1 tests your knowledge of strings, reading from les, and data structures. This assignment allows you to create a library of functions for use in later projects. Keep in mind that you will be using many of the functions you create in this phase of the simulator in future phases. Assignment 1 is designed as a data structures problem, and is not a part of the o cial simulator.
3.2 Speci cation
You will be given an arbitrary number of con guration les to read into your simulation program. Each con guration le will contain a version number (from 1-4), which will change the content of the con guration le and must be handled accordingly. Along with the con guration les, a number of test meta-data les will be given. You will need to read in the information on each le and display the metrics for them. The grader should be able to easily read your code, and run your program using the commands: make and ./Sim01 <CONFIG FILE. Name your le Sim01 for this assignment and include only the make le and any source or header les in your gzipped archive. Refer to the Expectations Section for how to submit your archive to Webcampus.
For the con guration le you will:
Output all of the cycle times in the format below Log to a le/monitor as speci ed
Read from the meta-data le speci ed
Log to the speci ed le location (ONLY if logging to the le)
4
For the meta-data le you will:
Output each operation and the total time for which it would run (e.g., O(hard drive)5 would run for 5 hard drive cycle time)
Additionally you will be required to:
handle le failures and typos (this includes a missing le, an incorrect le path, a typo in the le name, etc.)
handle meta-data and con guration typos (this includes misspellings in the con guration or meta data le, incorrect characters such as a colon instead of a semi-colon, etc.)
correctly identify and handle missing data (such as a missing processor cycle time or a time of 0)
utilize a (set of) data structure(s) to organize information and compute information through the data structure
open and close any les only once (for reading/writing only)
document EVERY function and data structure used throughout the program (anyone should look at your code and be able to read it like a book, you can nd examples of code documentation by running a search on it)
specify the con guration le as a command line argument use a make le
As a reminder, all of the functions created in this assignment will be used for your future assignments and are designed to help you easily transition from understanding data structures to actually applying them in the context of an operating system.
3.3 Example Con guration File
Start Simulator Configuration File
2 Version/Phase: 1.0
3 File Path: Test_1a.mdf
4 Monitor display time {msec}: 20
5 Processor cycle time {msec}: 10
6 Scanner cycle time {msec}: 25
7 Hard drive cycle time {msec}: 15
8 Keyboard cycle time {msec}: 50
9 Memory cycle time {msec}: 30
Projector cycle time {msec}: 10
Log: Log to Both
Log File Path: logfile_1.lgf
End Simulator Configuration File
3.4 Example Input
Start Program Meta-Data Code:
S{begin}0; A{begin}0; P{run}11; M{allocate}2;
O{monitor}7; I{hard drive}8; I{scanner}8; O{projector}20;
4 P{run}6; O{projector}4; M{block}6;
5 I{keyboard}17; M{block}4; O{projector}8; P{run}5; P{run}5;
6 O{hard drive}6; P{run}18; A{finish}0; S{finish}0.
7 End Program Meta-Data Code.
5
3.5 Example Output
Configuration File Data
2 Monitor = 20 ms/cycle
3 Processor = 10 ms/cycle
4 Scanner = 25 ms/cycle
5 Hard Drive = 15 ms/cycle
6 Keyboard = 50 ms/cycle
7 Memory = 30 ms/cycle
8 Projector = 10 ms/cycle
9 Logged to: monitor and logfile_1.lgf
10
Meta-Data Metrics
P{run}11 - 110 ms
M{allocate}2 - 60 ms
O{monitor}7 - 140 ms
I{hard drive}8 - 120 ms
I{scanner}8 - 200 ms
O{projector}20 - 200 ms
P{run}6 - 60 ms
O{projector}4 - 40 ms
M{block}6 - 180 ms
I{keyboard}17 - 850 ms
M{block}4 - 120 ms
O{projector}8 - 80 ms
P{run}5 - 50 ms
P{run}5 - 50 ms
O{hard drive}6 - 90 ms
P{run}18 - 180 ms
Assignment 2
4.1 Description
This will be the rst "phase" of your operating systems simulator. Phase 1 of the simulator will allow you to run a single program. You are tasked with running a stand-alone program through your simulator using many of the operations seen previously in test les.
4.2 Speci cation
You are required to run a single program through your simulator. This must be timestamped for each oper-ation start and completion. You are also required to use a PCB(process control block) to update the state of your program: START, READY, RUNNING,WAITING, EXIT. Depending on what is speci ed by the given con guration le, all operations must be printed to the screen, a le, or both. Lastly, you must allocate memory for the single program .You will notice that there is a new line in the con guration le specifying system memory. You will be required to take in the memory of the system (in kbytes, Mbytes, or Gbytes) convert to kbytes in needed, randomly generate a number and convert that number to hexadecimal for this project.
You will be required to:
use a 5-state PCB to change the state of your process
6
use a timer to complete every operation in real time as well as timestamp the start and end of each operation (more details available at the end of the document)
use the given memory allocation function and display the location at which your newly allocated memory resides
use dedicated threads for each I/O operation (you may NOT use threads created by a library, you must create the threads yourself)
elegantly handle all errors including typos, le failures, missing data, etc.
Since at this point all the operations are linear one way to use the PCB to change the state of your process is:
Have a struct named PCB with an integer named processState.
Assign integer values for start, ready, running, wait, exit at the beginning of your Sim02.cpp. declare an PCB object in the main.
at the correct instance assign the appropriate state.
Use the system timer to print the time at the start and the end of every operation. The only requirement (at this time) for the memory function is that the random value is an unsigned int which will be printed as a hexadecimal address.
4.3 Timer Usage
You will be required to use a timer to accurately timestamp all of your simulator's actions. This means that a projector operation running for 6 cycles will have to physically run for 6 projector cycle time. The simulator must output a timestamp at the beginning of the projector operation and another timestamp at the end of the operation. You are required to use the system clock. The timer itself must be measurable to the microsecond level and accurate to the millisecond level. For example, the output below should run for 7.387 seconds, outputting the correct timestamps for each operation. In addition, you are required to create your own timer thread to count down from a particular milliseconds to 0. For example, a process is expected to run a projector operation for 7387 milliseconds, your simulator will set the timer to 7387 and the timer will automatically counting down to 0 by using the system clock. Your program should also keep checking every 100 milliseconds to see whether the timer expired.
4.4 Thread Usage
You are required to complete each input and output operation (designated by I and O respectively) by creating a new thread for the operation and waiting for it to complete. The threads must only be used for I/O operations to best simulate the hands-o role of an OS in controlling external devices. For documentation on thread usage see the pthread man page or the POSIX tutorial at: https://computing. llnl.gov/tutorials/pthreads/.
4.5 Example Con guration
Start Simulator Configuration File
2 Version/Phase: 1.0
3 File Path: Test_1a.mdf
4 Monitor display time {msec}: 20
5 Processor cycle time {msec}: 10
6 Scanner cycle time {msec}: 25
7 Hard drive cycle time {msec}: 15
8 Keyboard cycle time {msec}: 50
7
Memory cycle time {msec}: 30
Projector cycle time {msec}: 10
System memory {kbytes}: 1024
Log: Log to Both
Log File Path: logfile_1.lgf
End Simulator Configuration File
4.6 Example Input
Start Program Meta-Data Code:
S{start}0; A{start}0; P{run}11; M{allocate}2;
3 O{monitor}7; I{hard drive}8; O{projector}20;
4 P{run}6; O{projector}4; M{block}6; I{keyboard}17;
5 M{block}4; P{run}5; P{run}5; O{hard drive}6;
6 P{run}18; A{end}0; S{end}0.
7 End Program Meta-Data Code.
4.7 Example Output
0.000001 - Simulator program starting
2 0.000051 - OS: preparing process 1
3 0.000053 - OS: starting process 1
4 0.000055 - Process 1: start processing action
5 0.132061 - Process 1: end processing action
6 0.132063 - Process 1: allocating memory
7 0.182066 - Process 1: memory allocated at 0x00000000
8 0.182069 - Process 1: start monitor output
9 0.392073 - Process 1: end monitor output
0.392074 - Process 1: start hard drive input
0.536077 - Process 1: end hard drive input
0.536079 - Process 1: start projector output
5.536081 - Process 1: end projector output
5.536085 - Process 1: start processing action
5.608088 - Process 1: end processing action
5.608089 - Process 1: start projector output
6.608094 - Process 1: end projector output
6.608097 - Process 1: start memory blocking
6.758099 - Process 1: end memory blocking
6.758101 - Process 1: start keyboard input
6.843104 - Process 1: end keyboard input
6.843106 - Process 1: start memory blocking
6.943109 - Process 1: end memory blocking
6.943110 - Process 1: start processing action
7.003114 - Process 1: end processing action
7.003116 - Process 1: start processing action
7.063119 - Process 1: end processing action
7.063127 - Process 1: start hard drive output
7.171130 - Process 1: end hard drive output
7.171134 - Process 1: start processing action
7.387137 - Process 1: end processing action
7.387158 - OS: removing process 1
8
7.387433 - Simulator program ending
9
