-
Notifications
You must be signed in to change notification settings - Fork 0
dugancathal/scheduler
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Folders and files
Name | Name | Last commit message | Last commit date | |
---|---|---|---|---|
Repository files navigation
Group: TJ Taylor Hours Spent: TJ Taylor: 20 hours File Structure: . ├── .gitignore -- Listing of all files for git to ignore. ├── competition.input -- The competition input file. ├── README -- README file └── src ├── clock.rb -- Implementation of a system clock. Updates all Timer objects currently in Ruby's stack ├── feedback_process_queue.rb -- Implementation of a Queue. (Push/Pop) Basically a Ruby Array wrapper ├── logger.rb -- Implementation of a system logger. Essentially an array that holds the transitions. ├── parser.rb -- Parser class to read the simulation input file. ├── process.rb -- Abstraction of a process. Handles multiple threads per process. ├── process_table.rb -- Basic process table implementation. Has a ready_queue, blocked_queue, and currently_running_thread ├── round_robin_scheduler.rb -- Implementation of the Round Robin Scheduler. (No Preemption) ├── scheduler.rb -- The base scheduler class. ├── sim -- The driver program ├── simulation_scheduler_process_table.rb -- The competition ready Process Table Implementation. ├── simulation_scheduler.rb -- The competition ready Scheduler Implementation. ├── statistician.rb -- Container class to hold completed process/thread details and printing. ├── system.rb -- Abstraction of the System. Handles kicking off the scheduler ├── terminal-table -- Obtained from the gem by VisionMedia@github. Documentation available at https://github.com/visionmedia/terminal-table │ ├── cell.rb │ ├── core_ext.rb │ ├── import.rb │ ├── row.rb │ ├── separator.rb │ ├── style.rb │ ├── table_helper.rb │ ├── table.rb │ └── version.rb ├── terminal-table.rb -- Primary TerminalTable loading file. Adds TerminalTable to top level namespace ├── thread.rb -- Implementation of a thread per the project definition. ├── thread_timeline.rb -- Container Class for all Processes/Threads that have not yet arrived └── timer.rb -- A timer with an alarm and snooze button Instructions: To run the simulator, you can simply 'cd' into the 'src' directory and run './sim' The simulator allows for 'detailed' and 'verbose' modes (detailed mode provides more statistics about the processes/threads that ran, while verbose mode provides details about what state transitions occurred at what times). If a filename is provided AS THE LAST ARGUMENT, that file is used for the simulation. (e.g. ./sim simulation.input) Unusual/Intersting Features: I provided one additional scheduling algorithm in addition to my competition algorithm: Round Robin Scheduling. To invoke this algorithm, you can supply a '-t' option with 'RoundRobinScheduler' as the argument. (e.g. ./sim -t RoundRobinScheduler) Also, I provided the TerminalTable gem to help with outputting tables of data. This was included to format the output in a more consistent, orderly fashion. Hardest Part: The hardest part of this project was wrapping my mind around the scheduling concepts, and implementation of a clock that could update all of my timers(without threading). Comments: Essay: My design and algorithm are an implementation of a 4-Tier Multilevel Feedback-Queue scheduler. This primarily entails a set of FIFO queues that hold processes until their turn on the CPU. Each queue has an associated quantum (time-limit) that denotes how long a process from that queue gets the CPU (in the final submission, those quanta are 6,8,10, and 16 time units). This allows smaller processes, or at least processes with shorter CPU bursts, the time to finish and get on to their I/O time. Q&A: a) Does the simulator include overhead for the first ready to running-state transition? Answer) Yes b) Does your simulator include switch overhead if a thread moves from ready state to running state and the CPU is idle? Explain. Answer) Yes In order for the thread to get put on the CPU, there must be some overhead associated. Even if the CPU is idle, it must still load the TCB, and perform other preparatory tasks. c) Does your simulator include switch overhead if a thread moves from running state to blocked state and the ready queue is empty? Explain. Answer) No Per the project description, there was not overhead associated with moving a process from running to blocked. However, in a real system there would be some overhead involved here (ie. dispatching the job to the I/O device or whatever it was using) d) Does your simulation include switch overhead if a thread is interrupted (due to a timeslice) and either the ready queue is empty or the thread has the highest priority? Explain. Answer) No Because the thread is the same, and no other process/thread has been loaded onto the CPU, the TCB can stay intact, and no reloading is necessary when that thread regains the CPU.
About
A Ruby implementation of a Multi-level Feedback Queue Scheduler
Resources
Stars
Watchers
Forks
Releases
No releases published
Packages 0
No packages published