Turnin method: Take your all project files (.java, .class, .sln, etc), traces of several test, and your experimental write-up (also a readme.txt woulde be preferred) and zip or tar/gzip them into a single file. Send via attachment to cse451-TA@cs.washington.edu.
Required turn-in parts
Turn in a copy of your program and traces of several test runs that
illustrate all of the required and interesting features of your program.
Also, give a brief evaluation and discussion of your results. Grading will
be be based on program style, correctness, efficiency, documentation, test
case selection, and any interesting insights that you offer on your results
and design.
Note: In addition to the above, please also turn in a mapping (in words or graphs) between the resulting system (the one you ended up implementing) and the logical view of the layering.
The goal of this project is to design and implement some operating system threads and monitors that control the execution of a varying number of simulated user jobs running on a shared memory multiprocessor.
Systems Organization
See figure (below). All OS functions are executed on one processor, the one that you are actually using. The Run_User_Job phase of each Executer is run on a separate (simulated) processor dedicated to that Executer.
User Job Definitions: Job definitions are entered dynamically from your terminal. Each job is specified by the following data items:
<name> - character string, < 6 characters in length.
<execution time> - positive integer (time units).
<main storage requirements> - positive integer (blocks of
storage), < 41 .
System State
This data structure has a node or record for each user job in the system. Each node contains the user job definition data described above, as well as the following:
<entry time> - time that the job entered the system.
<status> - either running (if its Executer is in its Run_User_Job
phase) or waiting_for_storage (if its Executer has not received its required
storage).
<storage allocation time> - time that its Executer received
its required storage.
Threads
1. Executers: An Executer thread controls the execution of a user job. There are a fixed number n of Executers, n < 9. Each Executer loops through the following steps:
(i) Remove a new job from the input Bounded_Buffer. Do this only if no Executers are waiting for storage, as determined by examining the System State.2. Display_State: On request from the terminal (via the Binary_Semaphore), this thread displays the current System State.
(ii) Update the System State by inserting a record for the new job.
(iii) Obtain the required storage from the Storage_Manager and update the job record after the storage has been allocated.
(iv) Run_User_Job phase: Simulate the execution of the job by using a wakeme call on the Alarm_Clock monitor.
(v) Terminate the job by releasing its storage, removing its record from the System State, and sending a completion message through the output Bounded_Buffer to the screen. The completion message should contain the job's System State data (less the <status> field) and the job termination time.
3. Input: Requests to either display the System State or to define a new job are received by the Input thread and transmitted to the appropriate handler through the Binary_Semaphore or input Bounded_Buffer, respectively.
4. Output: This thread displays completion messages or System State, through the output Bounded_Buffer.
5. Ticker: The purpose of the Ticker thread is to emit periodic tick
calls to the Alarm_Clock. How can you do this?
Monitors
1. Bounded_Buffers: Assume that the input buffer has a capacity of 2 user job definitions, and that the output buffer can hold up to 5 job records.
2. Storage_Manager: This monitor manages a pool of b blocks of storage, where 41 < b < 181.
3. RW_Manager: This monitor controls read/write access to the System State and performs the same functions as the RW_Manager of your first program.
4. Binary_Semaphore: This is used to communicate between the Input and Display_State threads.
5. Alarm_Clock: This monitor performs the standard alarm clock functions (Homework#3). Note that Java monitors do not have priority waits.
Here is the graph for the system organization: