How Operating Systems Decide What Runs Next
by Froga
How a scheduler picks which process gets the CPU, and what goes wrong when it picks badly. For anyone curious what actually happens between pressing a key and seeing it appear on screen.
You're previewing this room. Log in or create a free account to answer the questions and track your progress.
Study material
An operating system keeps every process in one of a few states: running (actively using the CPU), ready (waiting for a turn), or blocked (waiting on something like a disk read or a network reply). A component called the scheduler decides, many times per second, which ready process gets the CPU next. Moving a process out of the running state means recording exactly where it stood, so it can pick up later without losing progress.
A running process is paused and its registers, program counter and memory mappings are saved so it can resume exactly where it left off. What is this event called, and why do schedulers avoid triggering it too often?
multiple choice
AA page fault; the CPU must reload the program's code from disk before it can continue running.
BA context switch; frequent switching wastes CPU time on saving and restoring state instead of real work.
CA deadlock; the paused process can never be scheduled again once another process takes the CPU.
DA system call; control must pass into the kernel every time a process stops running.
The state has to go somewhere before another process can use the same registers.
Log in to answer
Ready to test yourself?
Sign up free to answer, score points, and build your streak.