Hello, dear friend, you can consult us at any time if you have any questions, add WeChat: THEend8_
Simulation Project Part II (document version 1.0)
Processes and CPU Scheduling
Overview
• This assignment is due in Submitty by 11:59PM EST on Thursday, August 15, 2024
• This project is to be completed either individually or in a team of at most three students; as with Project Part I, form your team within the Submitty gradeable, but do not submit any code until we announce that auto-grading is available
• NEW: If you worked on a team for PartI, feel free to change your team for Part II; all code is reusable from Part I even if you change teams
• Beyond your team (or yourself if working alone), do not share your code; however, feel free to discuss the project content and your findings with one another on our Discussion Forum
• To appease Submitty, you must use one of the following programming languages: C, C++, or Python (be sure you choose only one language for your entire implementation)
• You will have five penalty-free submissions on Submitty, after which points will slowly be deducted, e.g., -1 on submission #6, etc.
• You can use at most three late days on this assignment; in such cases, each team member must use a late day
• You will have at least three days before the due date to submit your code to Submitty; if the auto-grading is not available three days before the due date, the due date will be 11:59PM EDT three days after auto-grading becomes available
• NEW: Given that your simulation results might not entirely match the expected output on Submitty, we will cap your auto-graded grade at 50 points even though there will be more than 50 auto-graded points per language available in Submitty
• All submitted code must successfully compile and run on Submitty, which currently uses Ubuntu v22.04.4 LTS
• If you use C or C++, your program must successfully compile via gcc org++ with no warning messages when the -Wall (i.e., warn all) compiler option is used; we will also use -Werror, which will treat all warnings as critical errors; the -lm flag will also be included; the gcc/g++ compiler is currently version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04)
• For source file naming conventions, be sure to use * .c for C and * .cpp for C++; in either case, you can also include * .h files
• For Python, you must use python3, which is currently Python 3.10.12; be sure to name your main Python file project .py; also be sure no warning messages or extraneous output occur during interpretation
• Please “flatten” all directory structures to a single directory of source files
• Note that you can use square brackets in your code
Project specifications
For Part II of our simulation project, given the set of processes pseudo-randomly generated in Part I, you will implement a series of simulations of a running operating system. The overall focus will again be on processes, assumed to be resident in memory, waiting to use the CPU. Memory and the I/O subsystem will not be covered in depth in either part of this project.
Conceptual design — (from Part I)
A process is defined as a program in execution. For this assignment, processes are in one of the following three states, corresponding to the picture shown further below.
• RUNNING: actively using the CPU and executing instructions
• READY: ready to use the CPU, i.e., ready to execute a CPU burst
• WAITING: blocked on I/O or some other event
RUNNING READY WAITING (on I/O) STATE STATE STATE
+-----+ +---------------------+
| | +-------------------+ | |
| CPU | <== | | | | | | I/O Subsystem |
| | +-------------------+ | |
+-----+ <<< queue <<<<<<<<< +---------------------+
Processes in the READY state reside in a queue called the ready queue. This queue is ordered based on a configurable CPU scheduling algorithm. You will implement specific CPU scheduling algorithms in Part II of this project.
All implemented algorithms (in Part II) will be simulated for the same set of processes, which will therefore support a comparative analysis of results. In Part I, the focus is on generating useful sets of processes via pseudo-random number generators.
Back to the conceptual model, when a process is in the READY state and reaches the front of the queue, once the CPU is free to accept the next process, the given process enters the RUNNING state and starts executing its CPU burst.
After each CPU burst is completed, if the process does not terminate, the process enters the WAITING state, waiting for an I/O operation to complete (e.g., waiting for data to be read in from a file). When the I/O operation completes, depending on the scheduling algorithm, the process either (1) returns to the READY state and is added to the ready queue or (2) preempts the currently running process and switches into the RUNNING state.
Note that preemptions occur only for certain algorithms.
Algorithms — (Part II)
The four algorithms that you must simulate are first-come-first-served (FCFS); shortest job first (SJF); shortest remaining time (SRT); and round robin (RR). When you run your program, all four algorithms are to be simulated in succession with the same initial set of processes.
Each algorithm is summarized below.