Solved–Project #5– Solution

Description

• 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 programs); 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

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;

10. P{run}10; P{run}13; P{run}9; P{run}15; P{run}6; P{run}13;

10. 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;

12. A{finish}0; S{finish}0.

12. 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

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

10. Log File Path: logfile_1.lgf

10. 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) 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

10. Projector cycle time {msec}: 10

10. Log: Log to Both

10. Log File Path: logfile_1.lgf

10. 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.

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

11. Meta-Data Metrics

11. P{run}11 – 110 ms

11. M{allocate}2 – 60 ms

11. O{monitor}7 – 140 ms

11. I{hard drive}8 – 120 ms

11. I{scanner}8 – 200 ms

11. O{projector}20 – 200 ms

11. P{run}6 – 60 ms

11. O{projector}4 – 40 ms

11. M{block}6 – 180 ms

11. I{keyboard}17 – 850 ms

11. M{block}4 – 120 ms

23. O{projector}8 – 80 ms

23. P{run}5 – 50 ms

23. P{run}5 – 50 ms

23. O{hard drive}6 – 90 ms

23. 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

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

9 Memory cycle time {msec}: 30

10. Projector cycle time {msec}: 10

10. System memory {kbytes}: 1024

10. Log: Log to Both

10. Log File Path: logfile_1.lgf

10. 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

10. 0.392074 – Process 1: start hard drive input

10. 0.536077 – Process 1: end hard drive input

10. 0.536079 – Process 1: start projector output

10. 5.536081 – Process 1: end projector output

10. 5.536085 – Process 1: start processing action

10. 5.608088 – Process 1: end processing action

10. 5.608089 – Process 1: start projector output

10. 6.608094 – Process 1: end projector output

10. 6.608097 – Process 1: start memory blocking

10. 6.758099 – Process 1: end memory blocking

10. 6.758101 – Process 1: start keyboard input

10. 6.843104 – Process 1: end keyboard input

10. 6.843106 – Process 1: start memory blocking

10. 6.943109 – Process 1: end memory blocking

10. 6.943110 – Process 1: start processing action

10. 7.003114 – Process 1: end processing action

10. 7.003116 – Process 1: start processing action

10. 7.063119 – Process 1: end processing action

10. 7.063127 – Process 1: start hard drive output

10. 7.171130 – Process 1: end hard drive output

10. 7.171134 – Process 1: start processing action

10. 7.387137 – Process 1: end processing action

10. 7.387158 – OS: removing process 1

10. 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

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

10. Scanner cycle time {msec}: 15

10. System memory {kbytes}: 2048

10. Memory block size {kbytes}: 128

10. Projector quantity: 4

10. Hard drive quantity: 2

10. Log: Log to File

10. Log File Path: logfile_1.lgf

10. 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;

• O{hard drive}2; O{hard drive}16; M{allocate}4;

• 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

10. X.XXXXXX – Process 1: start hard drive input on HDD 0

10. X.XXXXXX – Process 1: end hard drive input

10. X.XXXXXX – Process 1: start projector output on PROJ 0

10. X.XXXXXX – Process 1: end projector output

10. X.XXXXXX – Process 1: allocating memory

10. X.XXXXXX – Process 1: memory allocated at 0x00000080

10. X.XXXXXX – Process 1: start projector output on PROJ 1

10. X.XXXXXX – Process 1: end projector output

10. X.XXXXXX – Process 1: allocating memory

10. X.XXXXXX – Process 1: memory allocated at 0x00000100

10. X.XXXXXX – Process 1: start hard drive input on HDD 1

10. X.XXXXXX – Process 1: end hard drive input

10. X.XXXXXX – Process 1: start hard drive output on HDD 0

10. X.XXXXXX – Process 1: end hard drive output

10. X.XXXXXX – Process 1: start hard drive output on HDD 1

10. X.XXXXXX – Process 1: end hard drive output

10. X.XXXXXX – Process 1: allocating memory

10. X.XXXXXX – Process 1: memory allocated at 0x00000180

10. X.XXXXXX – Process 1: start processing action

10. X.XXXXXX – Process 1: end processing action

10. X.XXXXXX – Process 1: start projector output on PROJ 2

10. X.XXXXXX – Process 1: end projector output

10. X.XXXXXX – Process 1: start memory blocking

10. X.XXXXXX – Process 1: end memory blocking

10. X.XXXXXX – Process 1: start keyboard input

10. X.XXXXXX – Process 1: end keyboard input

10. X.XXXXXX – Process 1: start memory blocking

10. X.XXXXXX – Process 1: end memory blocking

10. X.XXXXXX – Process 1: start processing action

10. X.XXXXXX – Process 1: end processing action

10. X.XXXXXX – Process 1: start processing action

10. X.XXXXXX – Process 1: end processing action

10. X.XXXXXX – Process 1: start hard drive output on HDD 0

10. X.XXXXXX – Process 1: end hard drive output

10. X.XXXXXX – Process 1: start processing action

45. X.XXXXXX – Process 1: end processing action

45. X.XXXXXX – OS: removing process 1

45. X.XXXXXX – Simulator program ending

• Assignment 4

6.1 Description

Assignment 4 will allow you to increase throughput in your simulator by implementing scheduling algorithms.

6.2 Speci cation

You will now be required to implement your simulator with three scheduling algorithms.

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 this project, the following should be considered:

All processes must be scheduled based on the given algorithm. All I/O operations must continue to be threaded.

Each resource used by a process must be allocated, de-allocated, and re-allocated based on the maxi-mum resource number. Only projectors and hard drives will be manageable resources. Remember to lock your resources through mutexes while you are using them.

All memory allocated during a function must be kept available until the ENTIRE application completes, when it will be freed. If you run out of memory and need to allocate more for the current process, the freed memory will need to be re-allocated for the application that no longer has memory (but is not yet complete).

The possible scheduling algorithms possible are FIFO ( rst in rst out), PS (priority schedule) and SJF (shortest job rst). For PS the process with more number of input and output operations will be performed rst and continue in such a manner until the process with least number of input and output operations will be performed in the end. The SJF should count the total number of tasks in a process and the process with least number of tasks will be completed rst.

For this assignment you do not need to do anything with the processor quantum number.

For this assignment you will need to read the entire meta data content from S(start)0 to S(end)0 before performing any scheduling operation.

You are expected to create your own meta data les and con guration les at this point. You will be tested with multiple versions of meta data and con guration les that are not given to you. Your program should be robust enough to handle all of the test les previously and any variation upon them.

6.3 Example Con guration

• Start Simulator Configuration File

2 Version/Phase: 4.0

3 File Path: Test_4a.mdf

4 Processor Quantum Number: 1

5 CPU Scheduling Code: FIFO

6 Processor cycle time {msec}: 5

7 Monitor display time {msec}: 22

• Hard drive cycle time {msec}: 150

9 Projector cycle time {msec}: 550

10. Keyboard cycle time {msec}: 60

10. Memory cycle time {msec}: 10

10. Scanner cycle time {msec} : 30

10. System memory {kbytes}: 2048

10. Memory block size {kbytes}: 128

10. Projector quantity: 4

10. Hard drive quantity: 2

10. Log: Log to File

10. Log File Path: logfile_1.lgf

10. End Simulator Configuration File

6.4 Example Input

• Start Program Meta-Data Code:

• S{begin}0; A{begin}0; P{run}11; M{allocate}2; A{finish}0;

3 A{begin}0; O{hard drive}6; A{finish}0; A{begin}0; P{run}4;

4 I{keyboard}18; M{allocate}4; P{run}6; A{finish}0; S{finish}0.

5 End Program Meta-Data Code.

6.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 – End process 1

9 X.XXXXXX – OS: preparing process 2

10. X.XXXXXX – OS: starting process 2

10. X.XXXXXX – Process 2: start hard drive output

10. X.XXXXXX – Process 2: end hard drive output

10. X.XXXXXX – End process 2

10. X.XXXXXX – OS: preparing process 3

10. X.XXXXXX – OS: starting process 3

10. X.XXXXXX – Process 3: start processing action

10. X.XXXXXX – Process 3: end processing action

10. .

10. .

10. .

10. .

10. X.XXXXXX – End process 3

10. X.XXXXXX – Simulator program ending

• Assignment 5

7.1 Description

You will now be required to implement your simulator with two scheduling algorithms using interrupts.

7.2 Speci cation

All of your processes must be interruptible and never exceed the number of cycles speci ed by the quantum number. All of the I/O operations must continue to be threaded and should be handled by your simulator as they complete. The possible scheduling algorithms are Round Robin (RR) and Shortest time remaining (STR). All resources must be allocated according to the speci ed scheduling algorithm. In addition you need to use a dedicated load thread to reload the meta-data every 100ms for about 10 times to simulate the processes’ arrive time. Every time the meta-data is loaded, the applications must be treated independent of the previously loaded applications. Round Robin needs to have a dedicated thread to record time (50ms to interrupt)

7.3 Example Con guration

• Start Simulator Configuration File

2 Version/Phase: 5.0

3 File Path: Test_5a.mdf

4 Processor Quantum Number {msec}: 50

5 CPU Scheduling Code: RR

6 Processor cycle time {msec}: 5

7 Monitor display time {msec}: 22

8 Hard drive cycle time {msec}: 150

9 Projector cycle time {msec}: 550

10. Keyboard cycle time {msec}: 60

10. Memory cycle time {msec}: 10

10. System memory {kbytes}: 2048

10. Memory block size {kbytes}: 128

10. Projector quantity: 4

10. Hard drive quantity: 2

10. Log: Log to File

10. Log File Path: logfile_1.lgf

10. End Simulator Configuration File

7.4 Example Input

• Start Program Meta-Data Code:

• S{begin}0; A{begin}0; P{run}11; M{allocate}2; A{finish}0;

3 A{begin}0; O{hard drive}6; A{finish}0; A{begin}0; P{run}4;

4 I{keyboard}18; M{allocate}4; P{run}6; A{finish}0; S{finish}0.

5 End Program Meta-Data Code.

7.5 Example Output Format

At this point you should be familiar with the structure of the output. Below is the just the format on how the output should look like and it does not represent the correct order of scheduling.

1

• X.XXXXXX – Simulator program starting

3 X.XXXXXX – OS: preparing process 1

4 X.XXXXXX – OS: starting process 1

5 X.XXXXXX – Process 1: start processing action

6 X.XXXXXX – Process 1: interrupt processing action

7 X.XXXXXX – OS: preparing process 2

8 X.XXXXXX – OS: starting process 2

9 X.XXXXXX – Process 2: start hard drive output

10. X.XXXXXX – OS: preparing process 3

10. X.XXXXXX – OS: starting process 3

10. X.XXXXXX – Process 3: start processing action

10. X.XXXXXX – Process 2: end hard drive output

10. X.XXXXXX – Process 3: interrupt processing action

10. .

10. .

10. .

10. X.XXXXXX – OS: process 3 completed

10. X.XXXXXX – Simulator program ending

15