Multi Programming OS in Java

profilexxprakashxx
CSC227-Project-18-19-II.pdf_2.pdf

King Saud University

Computer Science Department

CSC227: Operating Systems

Course Project

Instructions:

 You can work in a group of not more than 3 students

 Last day to submit the project is: 7-April-2019

 To get the marks you (group) must demonstrate the project and explains the implementation.

Topic Multiprogramming OS Simulation Batch processing and Memory Allocation

Introduction

It is required in this project, to write a program in Java that simulates the behavior of the

multiprogramming operating system. At the end of the simulation, you are expected to

output some statistics regarding the behavior of the system and submit a report. In the

following sections, we will introduce the hardware specification, the multiprogramming

OS features and the jobs requirements.

Available computer system for the simulation has:

Hardware:

The computer hardware is assumed to have:

1. A RAM of size 256MB, where 16MB is used to store the OS. 2. A single core CPU that executes one instruction each unit of time. 3. An I/O device for input and output operations. 4. An internal clock that allows to measure time in milliseconds.

Operating System:

The operating system is the multiprogramming OS. We would be interested in only two

features in this simulation: The Job and CPU scheduling.

1. Job Scheduling: The system implements multiprogramming batch processing. 2. A long term scheduler selects jobs in sequence and allocates them the needed

memory until the 80% of the memory is full. A job is loaded only if there is enough

memory to satisfy its first memory requirement.

3. Each required memory block should be contiguous but a process may have more than one block of memory in different locations of the memory

4. The short term scheduler will allocate processes to the CPU following a multi-level feedback queue scheduling.

5. A process will have several CPU-burst / IO burst sequences at described in the example below. In each CPU burst a process may require additional memory or

decide to free part of its memory.

6. If a process requires additional memory and there is not enough memory to satisfy its request, it should be put in Waiting state until there is enough memory for it.

7. If all processes are in Waiting state, only if all waiting for memory allocation, this is a deadlock. The system should declare a deadlock and select the largest waiting process

to be killed in order to get some free memory for the other processes.

8. At any moment the processes will have one of the states, READY, WAITING, RUNNING, TERMINATED, KILLED.

9. When the job queue is empty and all processes are killed or terminated, the system should write a file containing statistics about all processes and their final status

TERMINATED or KILLED.

10. Every 100 milliseconds, the long term scheduler will wake-up, check the memory and load more jobs until the 80% of the memory is full.

Instructions:

1. You MUST use multithreading where the long-term (Job) scheduler runs in one thread while the short-term (CPU) scheduler runs in another thread.

2. Design the multi-level feedback queue however you see fit. Your design and implementation should include:

a. Number of queues. b. Scheduling algorithms for each queue. c. Method used to determine when to upgrade a process. d. Method used to determine when to demote a process.

Program specifications:

Each job in the jobs queue is defined as a sequence of several CPU-burst / IO burst as

follows:

Job description Explanation

Name

15 11

3

5 4

6

3 -6

1

3 0

-1

Process name

CPU-burst of 15ms – Memory required 11 MB

I/O burst of 3ms

CPU-burst of 5ms – Additional memory required 4 MB

I/O burst of 6ms

CPU-burst of 3ms – Free 6 MB of the allocated memory

I/O burst of 1ms

CPU-burst of 3ms – No change in memory

Job terminates after the last CPU-burst

Initialization phase:

You should perform the following steps before running the simulation:

1. Load all jobs in the jobs file into a jobs queue in memory 2. Start the system clock (in milliseconds) 3. Start the long term scheduler that check the first job in the job queue, check if there is

enough memory for it and then:

a. create a process for that job, b. allocate its memory c. put it in the Ready queue, d. remove it from the jobs queue

4. Load the RAM with the maximum number of user programs, then go to sleep for 200ms.

5. Start the simulation run which consists of a simulation of the Machine Execution Cycle. At each millisecond, the scheduler will check if a job CPU-burst has ended

and if the I/O burst of a process has ended. It should also check if any waiting process

can be reactivated and put in the ready queue.

Output from the simulation:

A text file containing statistics about all processes and their final status TERMINATED

or KILLED. Statistics about a process should contain:

a. Process ID b. Program name c. When it was loaded into the ready queue. d. Number of times it was in the CPU. e. Total time spent in the CPU f. Number of times it performed an IO. g. Total time spent in performing IO h. Number of times it was waiting for memory. i. Time it terminated or was killed j. Its final state: Killed or Terminated k. CPU Utilization l. Waiting time. m. Turnaround time.

You also should provide average waiting time and the average turnaround time for

Report:

A report is expected to discuss your design of the multi-level feedback queue scheduling,

justification of your design, and expectations in terms of performance, and analysis of the

results obtained. Visualize the waiting time and the turnaround time of the processes

using plots.

Bonus:

Build a graphical interface representing the multi-level feedback queue, CPU and the

memory and showing dynamically how memory is allocated or released by processes. In

addition, it has to show the processes waiting in the multi-level feedback queue. This

interface should show the time and the process under execution at any moment.