Job Processor Project Guide

Overview

The program simulates a computer with multiple processors by using a priority queue. The goal is to determine how many processors should be used to process jobs most efficiently. The jobs to be processed will be arriving into the system on a random basis using the following arrival times, with specific processing times for each job type:

Job Type Arrival Time Processing Time
A [4, 6] [1, 5]
B [6, 8] [2, 10]
C [8, 18] [6, 12]
D [14, 24] [9, 17]
Using the above table as requirements, we generate data consisting of:

This data is merged together using merge sort, ordered by arrival time (highest priority before regular priority, if there’s a tie). The arrival time is cumulative within each job type. Multiple different job types may arrive at the same time.

After creating all data sets, merging together, and sorting by arrival time, test data should look similar to this (as an example! This does not conform to all the above values):

Job Type Arrival Time Processing Time
A 6 2
B 10 8
A 12 4
A 18 3
B 19 9
A 24 3
D 25 13
A 25 3
A 34 1
C 35 12
B 38 10
A 40 4
A 46 5
B 48 8
A 51 5
C 51 15
B 58 8
A 61 3
A 66 2
B 67 9
A 70 5
A 74 1
C 77 14
B 78 8

Upon arrival a job will be placed on the waiting priority queue. If a processor is available, a job will be pulled from the priority queue. Once a job starts executing it runs to completion unless a “Highest Priority” job interrupts the running job. The interrupted job is removed from the processor, the remaining time is calculated and the job is placed back into the front of the priority queue, to be the next job executed as soon as a processor opens up (it’s arrival time should be the time it is placed back into the priority queue). If a “Highest Priority” job has the same arrival time, then the interrupted job goes behind it in the queue.

The simulation should run for 500 time units so you can generate initial report metrics. Then, continue to run for an additional 9500 time units time units before reporting final metrics:

Metrics Layout
Number of processor(s) being used: [value]
Current queue size: [value]
Average queue size: [value]
Maximum jobs in queue: [value]
Total time jobs are in queue: [value] time units
Average time jobs are in queue: [value] time units
Total number of A jobs arrived: [value]
Total number of A jobs completed: [value]
Total number of B jobs arrived: [value]
Total number of B jobs completed: [value]
Total number of C jobs arrived: [value]
Total number of C jobs completed: [value]
Total number of D jobs arrived: [value]
Total number of D jobs completed: [value]
Total jobs completed: [value]
Total time CPU(s) were processing: [value] time units
Total time CPU(s) were idle: [value] time units

Each test run creates a log file of actions (sample below from 2 CPU test). Run Time and Idle Time reset to 0 when a processor toggles from run to idle or idle to run:

Actions Log Layout
Time 1: Queue: Empty; CPU 1 Idle Time:1; CPU 2 Idle Time:1;
Time 2: Queue: Empty; CPU 1 Idle Time:2; CPU 2 Idle Time:2;
Time 3: Queue: Empty; CPU 1 Idle Time:3; CPU 2 Idle Time:3;
Time 4: Queue: Empty; CPU 1 Idle Time:4; CPU 2 Idle Time:4;
Time 5: Arrival: Overall Job:1, Job A:1, Processing Time 6;
Time 5:- Begin Processing Job:1, Job A:1 in CPU 1
Time 5:- Queue: Empty; CPU 1 Run Time:0; CPU 2 Idle Time:5;
Time 6: Queue: Empty; CPU 1 Run Time:1; CPU 2 Idle Time:6;
Time 7: Queue: Empty; CPU 1 Run Time:2; CPU 2 Idle Time:7;
Time 8: Arrival: Overall Job:2, Job A:2, Processing Time 3;
Time 8:- Begin Processing Job:2, Job A:2 in CPU 2
Time 8:- Queue: Empty; CPU 1 Run Time:3; CPU 2 Run Time:0;
Time 9: Queue: Empty; CPU 1 Run Time:4; CPU 2 Run Time:1;
Time 10: Arrival: Overall Job:3, Job B:1, Processing Time 6;
Time 10:- Queue: 1 Job; CPU 1 Run Time:5; CPU 2 Run Time:2;
Time 11: Complete Processing Job:1, Job A:1
Time 11:- Complete Processing Job:2, Job A:2
Time 11:- Begin Processing Job:3, Job B:1 in CPU 1
Time 11:- Queue: Empty; CPU 1 Run Time:0; CPU 2 Idle Time:0;

Analysis and Review

The metrics collected will be used to determine from a potentially infinite number of processors, how many processors should be used to process jobs most efficiently. A high number of jobs in the queue (i.e. long wait times to process) or a continually empty queue (i.e. no task ever has to wait to be processed) both reflect an ineffective processing environment. The correct answer is somewhere in between. The simulation will run multiple times, changing the number of processors each time (but always using the same original data file) in order to collect sufficient metrics to make an informed opinion.