$29
Project #3 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
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
2
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
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
3
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
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
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
4
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) 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
5
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.
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.
6
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
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/.
7
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
9 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
8
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
7.387433 - Simulator program ending
Assignment 3
5.1 Description
Assignment 3 will test your knowledge of multiprogramming and resource management. You will run multiple processes and handle their use of resources through mutexes and semaphores.
5.2 Speci cation
You will be required to implement a resource management system. You will use your own implementation of mutex locking and semaphores to manage the quantity of resources in your program. For all resources except the resources speci ed in the con guration le, you may assume their quantity to be one. The only resources you need to manage are the input and output resources. For example, when the keyboard is accessed you must manage the use of a keyboard in your program in a creative way. Since the keyboard is an example of a resource that cannot be accessed while it is being used, you need to design a mutex lock to guarantee that no other threads or processes could access it. As nothing is running concurrently (but will be in later assignments) it is in your best interest to design this system with concurrency in mind. This assignment does not require the use of resource management to function, but will ease your time spent programming for the nal assignment.
In addition to designing a resource management system, you are also required to design a memory function that allocates memory for your simulator. It must resemble the memory function given in Assignment 2, but you must nd a memory address at the beginning of every block (speci ed once again by the con guration le). For example, the rst memory access should output the address of 0x00000000. The next memory access should output the starting address of the next block. If/when you run out of blocks, the function should start again at the rst block (0x00000000). You should output each address in 32-bit hexadecimal, using an unsigned int.
Note: The times for each operation should equate to the physical time for each discrete operation and the corresponding cycle time. Here I have placed an "X" to indicate that the time should be calculated by you.
For each operation, the following should be considered:
All I and O operations must be threaded
All M fallocateg should have a hexadecimal address returned (within the constraints of the total memory given by the con guration)
Each resource (projector, keyboard, etc.) should use mutex locks and semaphores to control access from other simulator operations
The Mfblockg operation doesn't need to be handled other than running it for the allotted time until later assignments
9
The quantity value for projector and hard drive must be printed and your code should reset back to 0 after reaching the maximum quantity value.
5.3 Example Con guration
Start Simulator Configuration File
2 Version/Phase: 3.0
3 File Path: Test_3a.mdf
4 Processor cycle time {msec}: 5
5 Monitor display time {msec}: 22
6 Hard drive cycle time {msec}: 150
7 Projector cycle time {msec}: 550
8 Keyboard cycle time {msec}: 60
9 Memory cycle time {msec}: 10
Scanner cycle time {msec}: 15
System memory {kbytes}: 2048
Memory block size {kbytes}: 128
Projector quantity: 4
Hard drive quantity: 2
Log: Log to File
Log File Path: logfile_1.lgf
End Simulator Configuration File
5.4 Example Input
Start Program Meta-Data Code:
S{begin}0; A{begin}0; P{run}11; M{allocate}2;
3 O{monitor}7; I{hard drive}8; O{projector}20;
4 M{allocate}4; O{projector}6; M{allocate}3; I{hard drive}7;
5 O{hard drive}2; O{hard drive}16; M{allocate}4;
6 P{run}6; O{projector}4; M{block}6; I{keyboard}17;
7 M{block}4; P{run}5; P{run}5; O{hard drive}6;
8 P{run}18; A{finish}0; S{finish}0.
9 End Program Meta-Data Code.
5.5 Example Output
X.XXXXXX - Simulator program starting
2 X.XXXXXX - OS: preparing process 1
3 X.XXXXXX - OS: starting process 1
4 X.XXXXXX - Process 1: start processing action
5 X.XXXXXX - Process 1: end processing action
6 X.XXXXXX - Process 1: allocating memory
7 X.XXXXXX - Process 1: memory allocated at 0x00000000
8 X.XXXXXX - Process 1: start monitor output
9 X.XXXXXX - Process 1: end monitor output
X.XXXXXX - Process 1: start hard drive input on HDD 0
X.XXXXXX - Process 1: end hard drive input
X.XXXXXX - Process 1: start projector output on PROJ 0
X.XXXXXX - Process 1: end projector output
10
X.XXXXXX - Process 1: allocating memory
X.XXXXXX - Process 1: memory allocated at 0x00000080
X.XXXXXX - Process 1: start projector output on PROJ 1
X.XXXXXX - Process 1: end projector output
X.XXXXXX - Process 1: allocating memory
X.XXXXXX - Process 1: memory allocated at 0x00000100
X.XXXXXX - Process 1: start hard drive input on HDD 1
X.XXXXXX - Process 1: end hard drive input
X.XXXXXX - Process 1: start hard drive output on HDD 0
X.XXXXXX - Process 1: end hard drive output
X.XXXXXX - Process 1: start hard drive output on HDD 1
X.XXXXXX - Process 1: end hard drive output
X.XXXXXX - Process 1: allocating memory
X.XXXXXX - Process 1: memory allocated at 0x00000180
X.XXXXXX - Process 1: start processing action
X.XXXXXX - Process 1: end processing action
X.XXXXXX - Process 1: start projector output on PROJ 2
X.XXXXXX - Process 1: end projector output
X.XXXXXX - Process 1: start memory blocking
X.XXXXXX - Process 1: end memory blocking
X.XXXXXX - Process 1: start keyboard input
X.XXXXXX - Process 1: end keyboard input
X.XXXXXX - Process 1: start memory blocking
X.XXXXXX - Process 1: end memory blocking
X.XXXXXX - Process 1: start processing action
X.XXXXXX - Process 1: end processing action
X.XXXXXX - Process 1: start processing action
X.XXXXXX - Process 1: end processing action
X.XXXXXX - Process 1: start hard drive output on HDD 0
X.XXXXXX - Process 1: end hard drive output
X.XXXXXX - Process 1: start processing action
X.XXXXXX - Process 1: end processing action
X.XXXXXX - OS: removing process 1
X.XXXXXX - Simulator program ending
11
