RTOS Scheduler Simulation
Watch a scheduler switch between three tasks of different priority. Compare preemptive and non-preemptive scheduling, cause missed deadlines with a long task, and create priority inversion with a mutex, then fix it with priority inheritance.
Loading the 3D scene
Controls
Execution trace last 80 ms
Solid spans are running, faint spans are ready but waiting, red spans are waiting for the mutex.
Measurements
- CPU utilisation
- -
- Worst sensor response time
- -
- Missed deadlines
- 0
- Mutex held by
- -
Try this
- Each level is one task. Higher levels have higher priority. The yellow marble is the CPU, sitting on the level of the task that is running.
- With the initial settings the sensor task wakes every 10 ms, uses 2 ms and leaves. Each time, the task below stops and later carries on. That is preemption.
- Change scheduling to Non-preemptive. Now the sensor task waits until the lower task finishes, and "Worst sensor response time" grows a lot.
- Go back to preemptive and push Comms execution time to the maximum. The lowest task, display, stops getting its turn and begins to miss deadlines.
- Set the shared resource to Mutex to get priority inversion. If the sensor wakes while display holds the mutex it must wait, and meanwhile the comms task cuts in, so the sensor waits far longer.
- With Mutex + priority inheritance, the display task briefly inherits the sensor's priority while it holds the mutex, finishes quickly and releases it.
How to read it
The scheduler has one rule: run the highest-priority task that is ready. A preemptive scheduler switches the moment a higher task becomes ready. A non-preemptive one switches only when the running task gives up the CPU.
The deadline is the start of the next period. A job that has not finished by then counts as a missed deadline.
The periods and execution times here are example values. Context-switch time is not modelled.
This lab is also available in Korean. More labs: all 3D labs.