Program 2

Program 2
Due: February 26, 2009

This program gives you an opportunity to use data structures in a realistic application, namely, a simulated operating system. The system simulated is very simple-two processors and a printer. Each CPU is capable of executing any user request. Requests will arrive randomly, each with a predetermined CPU time and printer time requirement. Each request will be handled by the CPU that has the smallest number of waiting requests at the time the request arrives. In case of a tie, the request will go to CPU#1. Execution will be in dedicated mode, i.e., when a CPU starts handling a request, it cannot be interrupted to do anything else. The idea of the simulation is to trace the flow of requests through the system. This is a discrete event simulation, which means that it is essentially driven by scheduled events with "time" moving in (arbitrary sized) steps between successive events.

Each server in the system (the CPUs and the printer) will have a queue of requests waiting to be served by it. These queues will initially be empty. As stated above, once a request enters a CPU queue, it stays in that queue until it is served by that CPU. In other words, requests cannot jump from one queue to the other. After execution by the CPU, each request will join the queue for the printer if it needs to print some output.

Input and Output

The input will consist of a file whose name is p2_data.txt containing a sequence of request specifications. We will be interested only in certain characteristics of each request. These are:

Arrival time
Required CPU time
Required printer time

The arrival of the first request will be at time 0. All three specified times will be integers. The required CPU time will be greater than 0, and the required printer time can be greater than or equal to 0. Each line of the file will contain the three numbers describing one request. An example of such a file is the three lines below, which you might want to cut out and make into a file to test your program. (You should test it with other data, too.)

(Arrival)   (CPU)   (Print)
---------------------------------cut here---------------------------------
   0         50       49
  12         30       18
  38         24       10
---------------------------------cut here---------------------------------

The output will consist of a log of events and some performance statistics, written to a file whose name is logfile.txt. There are five types of events:

Request arriving
Execution begins
Execution ends
Printing begins
Printing ends

If a request has required printer time equal to 0, it will generate only the first three types of events. A sample log file for the input above would be:

Time  Request#     Event
---------------------------------------------
0        1         Arrives
0        1         Begins execution on CPU#1
12       2         Arrives
12       2         Begins execution on CPU#2
38       3         Arrives
42       2         Ends execution on CPU#2
42       2         Begins printing
50       1         Ends execution on CPU#1
50       3         Begins execution on CPU#1
60       2         Ends printing
60       1         Begins printing
74       3         Ends execution on CPU#1
109      1         Ends printing
109      3         Begins printing
119      3         Ends printing

Request numbers are assigned in order of arrival. Note also that the log must be written in order of time.

Program Structure

The program must use three queues for the three servers. Your program will also need other data structures. An important one will contain certain events that have not yet occurred, ordered by the time at which they will occur. These will be requests that will arrive, requests that have begun execution and will end execution, and requests that have begun printing and will end printing. Each of these events will be characterized by time the event will occur, request#, and type of event. Initially, this data structure will contain all the requests and their arrival times. You can use a sorted array-based list, a priority queue implemented by a heap, or some other ADT for this data structure.

All your important data structures should be implemented as class templates, as in the first assignment. That is, as data structures with associated operations applied to some generic class. You can use the templates provided by the text, templates from some version of the STL (in which case, you won't turn in the template code), or your own design. If you are designing your own ADT, you don't need to start with a pure virtual class as in Program 1, unless you want to, but the ADT should still be implemented as a class template. Whatever you do, follow the design principles of object-oriented programming. Yes - there are other ways to implement this assignment, but this way works for more complicated simulations, and you will lose points if you don't follow these directions. In particular, don't use a clock or timer to keep track of time and check if some event happens at each tick of the clock.

It is possible for race conditions to occur. These are two or more events that take place at the same time. Your simulator should list these events in increasing order of request#.

Turn in:

Hardcopy of all your source code.
Hardcopy of the log file generated by a run of your program. Use this test data.
Submit your source code files and an executable file named p2 by copying (or ftping) them to a specially designated directory in AFS. Each person in the class has a subdirectory which has the same name as your login name in /afs/cu/class/cs344jl
Within this individual directory, create a subdirectory named p2. Copy all your source files into your p2 directory, including header files, but no object or executable files. So, for example, if your login name was smithjd then your source files should be copied to /afs/cu/class/cs344jl/smithjd/p2. These directories have permissions set so that no one other than yourself and Prof. Lynch can read the files. You may, of course, use whatever operating system and compiler you wish to develop your code, but the version you turn in, both hardcopy and the files submitted to AFS, must compile with g++ and run under polaris.

Your grade on the program will be based on:

Proper implementation of all classes that the program uses. Follow the directions above. If you are using a template that you did not create, identify where it came from, and clearly identify and explain with comments any changes that you made to it.
Correctness of execution. Your program should run as a discrete event simulator as described above, and not as a loop that executes for each second of the simulated opsys.
You can assume the input data is correct, so you don't have to check for user errors, but you should make sure the program can handle any sequence of up to 100 requests.
Readability of the code: commented and well-structured, so that it is clear what the algorithms and data structures are doing. Use an accepted C++ style. The style of the text is fine, or you can use whatever style you learned in previous courses. Whatever you do, be consistent. Also, the comments should describe all ADTs that are used but not written by you.
Appearance of the output. You don't have to use the format in the log file example above, but make sure the columns in the output are lined up nicely so that it's easy to read.
Timely submission of your program. All hardcopy must be turned in on the due date, either in class or to me by 3:00PM. Late programs will not be accepted. Printouts submitted electronically will be ignored.

Program 2 Due: February 26, 2009

Input and Output

Program Structure

Program 2
Due: February 26, 2009