In this lab, you will write a C program that will simulate an operating systems job scheduling policy to determine which process will be assigned the CPU when it becomes available. We will utilize a system of queues to simulate a sophisticated job scheduling mechanism, the multi-level feedback queue (MFQ)

The system behaves as follows:

• The system runs from INIT_TIME (usually 0) to FIN_TIME.
• Jobs enter the system with an interarrival time that is uniformly distributed between ARRIVE_MIN and ARRIVE_MAX.
• Once a job has finished a round of processing at the CPU, the probability that it completes and exits the system (instead of doing a disk read or network send, and then further computation) is QUIT_PROB.
• Once a job has been determined to continue executing, a probability function is used to determine whether it will do disk I/O or use the network. This probability is NETWORK_PROB.
• When a job needs to do disk I/O, it uses the disk that's the least busy, i.e., the disk whose queue is the shortest. (This might seem a bit silly, but we can pretend that each disk has the same information.) If the disk queues are of equal length, choose one of the disks at random.
• When jobs reach some component (CPU, disk1, disk2, or network), if that component is free, the job begins service there immediately. If, on the other hand, that component is busy servicing someone else, the job must wait in that component's queue.
• The queue for each system component is FIFO.
• When a job reaches a component (a different job leaves a component or the component is free, and this job is first in the queue), how much time does it spend using the component? This is determined randomly, at runtime, for every component arrival. A job is serviced by a component for an interval of time that is uniformly distributed between some minimum and maximum defined for that component. For example, you'll define: CPU_MIN, CPU_MAX, DISK1_MIN, DISK1_MAX, etc.
• At time FIN_TIME, the entire job simulation terminates. We can ignore the jobs that might be left receiving service or waiting in the queue when FIN_TIME is reached.

example:

when what

15 job1 arrives

1000000 simulation finished

when	what
15	job2 arrives
25	job1 finishes at CPU
100000	simulation finished

Each event in the event queue will be of a given type. It seems simplest to store these as named constants, e.g., something like CPU_FINISHED=1, DISK1_FINISHED=2, etc., and to write a handler function for each possible event type. We've just described what the handler for a job arrival event might do. As an example, what should a disk finished handler do? Remove the job from the disk, return the job to the CPU (determining how much CPU time it will need for the next CPU execution, seeing if the CPU is free and if not, add it to the CPU's queue just as we did previously). We should also look at the disk's queue (because the disk is now free). If the disk's queue isn't empty, we need to remove a job from its queue, determine how long the job will require using the disk, create a new "disk finished" event and add it to the event queue.

The network finished handler will behave in a similar way to the disk finished handler when the NETWORK_FINISHED event occurs.

The program will read from a text config file the following values:

• a SEED for the random number generator
• INIT_TIME
• FIN_TIME
• ARRIVE_MIN
• ARRIVE_MAX
• QUIT_PROB
• NETWORK_PROB
• CPU_MIN
• CPU_MAX
• DISK1_MIN
• DISK1_MAX
• DISK2_MIN
• DISK2_MAX
• NETWORK_MIN
• NETWORK_MAX