CS 446/646 - OS Simulator Specification Project 2

CS 446/646 - OS Simulator Specification

Contents
1 Introduction 1
2 Simulator Description 2
2.1 Expectations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2 Meta-Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.3 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.4 Running the Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.5 Turning in Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3 Assignment 1 4
3.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2 Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3 Example Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.4 Example Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.5 Example Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4 Assignment 2 6
4.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2 Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.3 Timer Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.4 Thread Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.5 Example Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.6 Example Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.7 Example Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1 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 significantly 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 file. ALL PROGRAMS MUST RUN AND COMPILE IN THE
ECC, OTHERWISE YOUR GRADE WILL RESULT IN A ZERO
1
2 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 first program(s); if you have an overlying strategy from the
beginning, extending each program will not be difficult
• 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 highquality 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
difficulty 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 file 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 effective 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 files through WebCampus.
The file for each student must be tarred and zipped in Linux as specified below, and must be able
to be unzipped on any of the ECC computers include any and all files necessary for the operation of
the program. Any extraneous files such as unnecessary library or data files will be cause for credit
reduction. The format for submission is Sim0X <LastNameFirstName.tar.gz where X represents the
specific 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 files, and run your
files. 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 file:
1 Start Program Meta-Data Code:
2 S{begin}0; A{begin}0; P{run}11; P{run}9; P{run}12;
3 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;
10 P{run}10; P{run}13; P{run}9; P{run}15; P{run}6; P{run}13;
11 P{run}11; P{run}5; P{run}6; P{run}7; P{run}12; P{run}11;
12 P{run}6; P{run}8; P{run}10; P{run}5; P{run}8; P{run}9; P{run}7;
13 A{finish}0; S{finish}0.
14 End Program Meta-Data Code.
2.3 Configuration
Each assignment will use a configuration file 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 information required to run the simulation correctly. All cycle times are specified 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 file 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 configuration will need to be
read in prior to running any processes. The configuration file will be key to setting the constraints under
which your simulation will run.
Below is an example configuration file:
1 Start Simulator Configuration File
2 Version/Phase: 2.0
3 File Path: Test_2e.mdf
4 Projector cycle time {msec}: 25
3
5 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
10 Log: Log to Both
11 Log File Path: logfile_1.lgf
12 End Simulator Configuration File
2.4 Running the Simulator
When running the simulator you will be required to input a single configuration file (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 configuration files should be used to
test your program, which you may modify for testing purposes as you see fit.
2.5 Turning in Assignments
All assignments will be turned into WebCampus. You must submit a zipped .tar.gz archive as specified
above. Inside the archive there should only be the files required to run the simulator (e.g., all source files,
all header files). No resource files are allowed. Late assignments will not be accepted.
3 Assignment 1
3.1 Description
Assignment 1 tests your knowledge of strings, reading from files, 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 official simulator.
3.2 Specification
You will be given an arbitrary number of configuration files to read into your simulation program. Each
configuration file will contain a version number (from 1-4), which will change the content of the configuration
file and must be handled accordingly. Along with the configuration files, a number of test meta-data files will
be given. You will need to read in the information on each file 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 file Sim01 for this assignment and include only the makefile and any source or
header files in your gzipped archive. Refer to the Expectations Section for how to submit your archive to
Webcampus.
For the configuration file you will:
• Output all of the cycle times in the format below
• Log to a file/monitor as specified
• Read from the meta-data file specified
• Log to the specified file location (ONLY if logging to the file)
4
For the meta-data file 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 file failures and typos (this includes a missing file, an incorrect file path, a typo in the file name,
etc.)
• handle meta-data and configuration typos (this includes misspellings in the configuration or meta data
file, 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 files 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 find examples of code documentation by running
a search on it)
• specify the configuration file as a command line argument
• use a makefile
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 Configuration File
1 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
10 Projector cycle time {msec}: 10
11 Log: Log to Both
12 Log File Path: logfile_1.lgf
13 End Simulator Configuration File
3.4 Example Input
1 Start Program Meta-Data Code:
2 S{begin}0; A{begin}0; P{run}11; M{allocate}2;
3 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
1 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
11 Meta-Data Metrics
12 P{run}11 - 110 ms
13 M{allocate}2 - 60 ms
14 O{monitor}7 - 140 ms
15 I{hard drive}8 - 120 ms
16 I{scanner}8 - 200 ms
17 O{projector}20 - 200 ms
18 P{run}6 - 60 ms
19 O{projector}4 - 40 ms
20 M{block}6 - 180 ms
21 I{keyboard}17 - 850 ms
22 M{block}4 - 120 ms
23 O{projector}8 - 80 ms
24 P{run}5 - 50 ms
25 P{run}5 - 50 ms
26 O{hard drive}6 - 90 ms
27 P{run}18 - 180 ms
4 Assignment 2
4.1 Description
This will be the first ”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 files.
4.2 Specification
You are required to run a single program through your simulator. This must be timestamped for each operation 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 specified by the given
configuration file, all operations must be printed to the screen, a file, or both. Lastly, you must allocate
memory for the single program .You will notice that there is a new line in the configuration file 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, file 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-off 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 Configuration
1 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
9 Memory cycle time {msec}: 30
10 Projector cycle time {msec}: 10
11 System memory {kbytes}: 1024
12 Log: Log to Both
13 Log File Path: logfile_1.lgf
14 End Simulator Configuration File
4.6 Example Input
1 Start Program Meta-Data Code:
2 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
1 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
10 0.392074 - Process 1: start hard drive input
11 0.536077 - Process 1: end hard drive input
12 0.536079 - Process 1: start projector output
13 5.536081 - Process 1: end projector output
14 5.536085 - Process 1: start processing action
15 5.608088 - Process 1: end processing action
16 5.608089 - Process 1: start projector output
17 6.608094 - Process 1: end projector output
18 6.608097 - Process 1: start memory blocking
19 6.758099 - Process 1: end memory blocking
20 6.758101 - Process 1: start keyboard input
21 6.843104 - Process 1: end keyboard input
22 6.843106 - Process 1: start memory blocking
23 6.943109 - Process 1: end memory blocking
24 6.943110 - Process 1: start processing action
25 7.003114 - Process 1: end processing action
26 7.003116 - Process 1: start processing action
27 7.063119 - Process 1: end processing action
28 7.063127 - Process 1: start hard drive output
29 7.171130 - Process 1: end hard drive output
30 7.171134 - Process 1: start processing action
31 7.387137 - Process 1: end processing action
32 7.387158 - OS: removing process 1
8
33 7.387433 - Simulator program ending
9