Description
Write a program that handles the basic data structures (i.e. the devices
and their queues) in an operating system.
The program should have two stages of operation, the “sys gen” section,
and the “running” section. During sys gen, the system installer (me) specifies
how many devices of each type (printer, disk, and CD/RW) are in the system.
You may assume (for now) that there is only one CPU.
During the running section you will have to handle system calls issued by
the process currently controlling the CPU as well as interrupts that signal
various system events. These calls and interrupts will actually be indicated
by keyboard input. Capital letters will be interrupts, lower case will indicate system calls. All queues will be FIFO. All interrupts will be handled
“atomically” (one can not interrupt an interrupt handling routine) and will
return control to the interrupted process. (From a practical point of view,
this means your simulation can handle the event without changing the PCB
or state of the process “in” the CPU.)
An “A” entered on the keyboard indicates the arrival of a process. The
handling routine should create a PCB for this process, generate a PID, and
enqueue the PCB into the Ready Queue. If the CPU is not occupied, the
first process in the Ready Queue should be passed to the CPU.
The process in the CPU can issue system calls. One of these is “t”, which
indicate that the process is terminating. The OS should recycle the PCB (but
not the PID), in other words reclaim the now unused memory.
Each non-CPU device has a “name” consisting of a letter and an integer.
The process currently in the CPU will request “printer 1” by issuing a “p1” on
the keyboard, and Printer 1 will signal an “interrupt” indicating completion
1
of the task at the head of its queue with a “P1” being entered at the keyboard.
Similarly, “d3” to request disk 3 and “D3” to signal D3’s completion. On
such a “task completed” interrupt the PCB for that process should be moved
to the back of the Ready Queue. After a system call (e.g. “p3”) is made, you
should prompt the process (that’s me) for various parameters. These should
include the file name, the starting location in memory (an integer), whether
the requested action is a “read” or a “write” (“r” or “w” on the keyboard;
You can only write to a printer, so no need to prompt it) and, if a write, how
long the file is. The PCB for this process and the associated information
should be enqueued to the appropriate device queue.
Finally, an “S” on the keyboard indicates a “Snapshot” interrupt (simulating a Big Button on the Sys-op’s console). The handling routine should
wait for the next keyboard input and, if “r”, show the PIDs of the processes
in the Ready Queue, if “p”, show the PIDs and printer specific information
of the processes in the printer queues, if “d”, do the same for the disks, and
show the CD/RW queues if it is a “c”. Be sure the contents of the queues
don’t scroll off of a 24 line screen.
Your program grade is based primarily on the correctness of its execution
and ease of use. This means you should conform to the specifications for
input (no extra henteris, good error trapping, etc.) as well as make the
output readable in the available screen space (an 80×24 character screen).
Email your source code with compile instructions for a Linux environment
before class on the due date. Be sure to specify what language the source
is in and which is the “main” file or files to be named as the argument to
the compiler. Do not submit files other than the code you write. If you are
sending only one or two files there is no need to “package” them. If you
are sending more than two files you should package them. Tar and zip are
fine. Please make sure that the files unpack into the same directory that the
source file is in, not into a subdirectory. If you are sending c++ code and I
can compile with g++ -o ~/temp/run.me *cpp then I don’t need a makefile.
If you do supply a makefile be sure that the executable is ~/temp/run.me.
Be modular, you will want to reuse this in later programs. Please remember that I will not make any changes to your code to get it to run: be sure to
run (and debug) your program from a “shell prompt”, not just from within
some integrated development environment. Remember, I will not run your
programs within the X Windowing System, just from a bash prompt, so it
is important to be sure output does not scroll off the screen before I get a
chance to read it.
2
