https://github.com/fredwangwang/cpu-scheduling-simulator
https://github.com/fredwangwang/cpu-scheduling-simulator
cpp scheduling-algorithms simulator
Last synced: about 1 year ago
JSON representation
- Host: GitHub
- URL: https://github.com/fredwangwang/cpu-scheduling-simulator
- Owner: fredwangwang
- License: mit
- Created: 2017-03-08T01:42:12.000Z (over 9 years ago)
- Default Branch: master
- Last Pushed: 2017-10-04T14:19:30.000Z (over 8 years ago)
- Last Synced: 2025-02-05T05:22:46.389Z (over 1 year ago)
- Topics: cpp, scheduling-algorithms, simulator
- Language: C++
- Size: 31.3 KB
- Stars: 0
- Watchers: 1
- Forks: 3
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# CPU Scheduling Simulator
Huan Wang
all source files are in src folder, which contains:
Brust.h // contains data structure for brust
Event.h // contains event data type
Parse_flag.h // contains methods to interpret flags
Parse_flag.cpp // implementation
Priority_type.h // const for representing priority
priority_type.cpp // implementation
Process.h // contains data structure for Process
Thread.h // contains data structure for Thread
Simulator.h // main logic controlling the program flow
Simulator.cpp // implementation
scheduling_algo:
Scheduling_algorithm.h // virtual class for all algorithms
algo_CUSTOM.h // custom algorithm
... // various implementations
interesting feature:
The implementation of the simulator and the scheduling algorithm are separated. The simulator can work with any scheduling as long as it is the child class of Scheduling_algorithm
Time:
10+?
For the custom algorithm, there are 4 priority queues used. Each of them holds the thread from different priorities. The priority queues themselves keep the oldest thread in the front to prevent starvation. And when scheduling, a weighted random choose is implemented for fairness (randomness is a good friend of fairness). The weight I used in the algorithm is 1:2:3:4 for batch:normal:interactive:system. If the selected priority doesn't have any ready threads in the queue, a thread is chosen in the decreasing order of priority (e.g. if there is ready threads in system queue, that thread is chosen). And to compensate the "uneven fairness" due to the weighted probability, a different time slice is assigned to different priorities. System has a shortest slice of 3 unit, interactive and normal can run up to 4 unit of time until preemption. And batch thread has the longest time of 7 units.
Combining random choosing and priority queues, this algorithm is good at resisting aging and starvation caused by different priorities. However, starvation is still possible. Starvation will happen only if the thread adding into the system much faster than the system can process. Because the newly added threads are considered as "oldest" threads to optimize for response time. This is a nice feature, but it will cause starvation if new threads keep coming all the time. The the scheduler will always pick the newly added threads.