This repository has been archived by the owner on Dec 26, 2019. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 2
btrepp/CITS2230-Process-Scheduler-Simulator
Folders and files
Name | Name | Last commit message | Last commit date | |
---|---|---|---|---|
Repository files navigation
ReadME Beau Treap 20261142 Jonathan Eng 20263557 1. Running Scheduler Usage: [Flag] [Scheduler] [Quantum] [Input File] [Memory Quantum] [-f] [Memoryoutputfile] [-h] [Htmloutputfile] Flag : -s Run Scheduler without memory management(default). -v Run Scheduler with memory management. Scheduler : FCFS First Come First Serve algorithm SPN Shortest Process Next algorithm SRT Shortest Remaining Time algoritm RR Round Robin algorithm Quantum : Set time quantum for use in round robin scheduler process Input File : File where jobs are to be loaded from Memory Quantum : Print memory usuage at quantum time selected (only if -v is set) [-f] : File to print memory usage to, defaults to vout.file Memoryoutputfile : File that print memory usuage prints into [-h] : Flag for HTML memory visualisation Htmloutputfile : File that Html memory visualisation prints into Examples: ./scheduler -s FCFS Jobs.txt Runs in scheduler mode using first come first serve algorithm using the jobs from Jobs.txt. ./scheduler -v RR 2 Jobs.txt 30 Runs in virtual memory mode using round robin algorithm with a time quanta of 2, view output of virtual memory at time quanta 30. 2. Job input file Format: Job[Number] [Arrivaltime] [Processtime] [Pages] Number : Index number that is assigned to the job Arrivaltime : Time quanta that the job is to arrive into the CPU, a whole number greater than or equal to 0 Processtime : Time quanta that the job requires the CPU to process for, must be a whole number greater than 0 Pages : Number of pages in memory the job requires before it can be processed, must be between 1 - 50 --------------------------------------------------------------------------------------------- Structure -Virtual CPU The simulator works by implementing a "virtual" cpu. The cpu is passed Job processes, and will schedule the next Job process based on the arguments supplied. The CPU gets the Job processes from the "virtual" memory if the virtual memory mode has been set, and continously processes the Jobs in the memory until all Job processes are completed. The memory part of the project simply keeps up with updating the Job processes in the "virtual" memory, clearing spaces in the memory when the memory is full when there are additional Jobs that still need to be processed by the CPU. -Memory Object: The memory gets loaded with Jobs from the Jobs text file. Before loading the Jobs into the memory, the memory gets searched first if the pages in the memory exist. If the number of pages already in the memory exists, and is sufficent for the Job process to be run then the program does not load in new pages but uses the existing pages in there already. If the number of pages is insufficient then load the pages in the memory via the LRU function until the the number of pages required is sufficient. The LRU(Least Recently Used) is a function to check for the least recently used pages in memory, so that in the event that the memory becomes full with pages from other Jobs the program can start removing pages from memory based on the least recently used algorithm. The "Virtual" memory structure contains the key information needed to store the individual pages required by the job processes as well as keeping track of the least recently used pages, the free pages in memory when processes are completed and no longer needs the memory space, and the list of Jobs that are being sent to the CPU to be processed. Sort The Job processes are sorted via the standard qsort function provided in C. The Job process list is sorted based on their arrival time to the CPU. Data Structure -List Macro: We constructed a generic linked list structure that can be used for other projects that require linked list data structures. This generic linked list structure contains access to the individual nodes on the list, the head and tail of the list and an iterator that can access the current and previous nodes on the list. -Job: The Job structure contains the job process name, the time of arrival to the CPU, the length of time required to be processed by the CPU, and the number of pages required by the job processed which only needs to be known if the virtual memory mode is used. -JobInMemory: The JobInMemory structure is used to store the jobs in the "virtual" memory. It keeps track of the number of pages required by each Job process and the location of where the Job process pages are in memory. -UnprocessedJob: The UnprocessedJob structure contains a pointer to the Job structure which is the Job process, and keeps track of the remaining process time for each Job process, which is important for the round robin algorithm, as the algorithm needs to keep track of how much process time is left for each Job process once its processed the set allocated quanta time. -JobScheduleResult: The JobScheduleResult structure keeps track of when a Job process is being run by the CPU. The structure contains the Job process and tracks the start time of when the Job process is being processed by the CPU and how long the CPU has been running the Job process. -Page: We had made a page structure that contains the pages that the Job process need inorder to be processed. The page structure keeps track of the Job process, the location to where it is stored in memory and the time that it was last accessed at, for the least recently used algorithm. -BONUS HTML VIS: As a special bonus, the program is able to run a visual step simulation of the memory as the program is stepping through the memory/clock cycles. The javascript shows the contents of each of the 50 frames in the memory by the Job number and colours the block accordingly to what job pages are allocated in thte memory. -Debug Files: We added the functionality of having debug statements to print out when we define the debug function in the file that runs the code. This is so that we can control the amount of debug print outs onto the command line to a sustainable and readable manner.
About
No description, website, or topics provided.
Resources
Stars
Watchers
Forks
Releases
No releases published
Packages 0
No packages published