On Windows, how do a process priority class and a thread's relative priority combine into what the scheduler runs, and what is priority boosting for?
answer
- thirty-two levels, two ranges
- class gives a base, thread offsets it
- dynamic 1-15 versus real-time 16-31
- waking up earns a temporary lift
- boost decays one level per quantum
basics
~20 sWindows ranks threads on 32 priority levels. The process priority class sets a base, the thread's relative priority shifts it, and the scheduler always runs the highest-priority ready thread, preempting lower ones. Temporary boosts lift threads in the dynamic range 1-15 so waiters and starved threads make progress.
solid answer
~50 sScheduling on Windows is per-thread, priority-driven and preemptive across 32 levels. Levels 1-15 are the dynamic range and 16-31 the real-time range. A thread's base priority comes from its process priority class — `NORMAL_PRIORITY_CLASS` is 8, `HIGH_PRIORITY_CLASS` 13, `IDLE_PRIORITY_CLASS` 4 — plus the thread's relative offset from `SetThreadPriority`, roughly -2 to +2. The scheduler runs the highest-priority ready thread, round-robins equal-priority threads for a quantum, and preempts immediately when something higher becomes ready. Boosting then patches the model's weaknesses: a thread gets a temporary bump when an I/O completes, when a wait on an event or semaphore is satisfied, or when its window receives input, and the balance set manager rescues threads starved for seconds by lifting them to 15 for one extended quantum. Boosts apply only in the dynamic range and decay one level per quantum back to base.
go deeper
Recall that Windows schedules threads, that priority is a number the scheduler compares, and that the highest-priority ready thread runs. Know that SetPriorityClass affects a process and SetThreadPriority an individual thread.
Explain how the class base and the thread offset add up, why 1-15 and 16-31 behave differently, and what the quantum does. Describe at least two boost triggers and the one-level-per-quantum decay back to base.
Demonstrate judgment: diagnose a latency complaint without touching priority, explain why the anti-starvation boost exists in the absence of priority inheritance, and describe the operational risk of a real-time thread that never blocks.
Own the policy question — when a workload genuinely needs scheduling isolation, argue for separating it onto its own hardware, job object or machine rather than encoding priority numbers in the application, and set the rule your teams follow for when raising priority is ever acceptable.
## The unit of scheduling is the thread Windows schedules threads, not processes. A process is a container for an address space, a handle table and a security context; it never runs. Its priority class matters only because every thread it owns derives a base priority from it. ## The 32 levels Priorities run 0 to 31. Level 0 is reserved for the zero-page thread. Levels 1-15 form the **dynamic range**, where ordinary work lives and where the kernel is allowed to adjust priorities. Levels 16-31 form the **real-time range**, which the kernel never adjusts — a real-time thread keeps exactly the priority you gave it and, if it never blocks, will happily starve everything below it, including many system threads. Entering `REALTIME_PRIORITY_CLASS` requires the *Increase scheduling priority* privilege (`SeIncreaseBasePriorityPrivilege`) for exactly that reason. ## Composing a base priority Two API calls produce the number: - `SetPriorityClass` picks the process class: `IDLE_PRIORITY_CLASS` (base 4), `BELOW_NORMAL_PRIORITY_CLASS` (6), `NORMAL_PRIORITY_CLASS` (8), `ABOVE_NORMAL_PRIORITY_CLASS` (10), `HIGH_PRIORITY_CLASS` (13), `REALTIME_PRIORITY_CLASS` (24). - `SetThreadPriority` applies a relative offset within that class: `THREAD_PRIORITY_LOWEST` (-2), `BELOW_NORMAL` (-1), `NORMAL` (0), `ABOVE_NORMAL` (+1), `HIGHEST` (+2). Two extremes saturate rather than offset: `THREAD_PRIORITY_IDLE` pins the thread near the bottom of its range and `THREAD_PRIORITY_TIME_CRITICAL` near the top (15 in the dynamic range, 31 in the real-time range). So a thread in a normal process at `THREAD_PRIORITY_HIGHEST` has base priority 10 — the same as a `THREAD_PRIORITY_NORMAL` thread in an above-normal process. The class is not a separate dimension; it is an offset origin. ```c SetPriorityClass(GetCurrentProcess(), ABOVE_NORMAL_PRIORITY_CLASS); /* base 10 */ SetThreadPriority(GetCurrentThread(), THREAD_PRIORITY_ABOVE_NORMAL); /* 10 + 1 = 11 */ ``` ## The dispatch rule and the quantum The rule is simple and strict: run the highest-priority ready thread on each processor. A thread that becomes ready at a higher priority than one currently running preempts it immediately — Windows does not wait for the running thread's quantum to expire. Threads of equal priority share the processor round-robin, each getting a **quantum**, after which the scheduler moves to the next ready thread at that level. Quantum length is a system policy rather than a constant. Client Windows defaults to short quanta with a boost for threads of the foreground process, which trades throughput for responsiveness; Server defaults to long, uniform quanta, which favours throughput for background services. Both are governed by the `Win32PrioritySeparation` value under `HKLM\SYSTEM\CurrentControlSet\Control\PriorityControl`, surfaced in the UI as the "programs" versus "background services" choice. Modern Windows accounts quantum consumption by CPU cycles rather than by charging whole clock ticks, so a thread that is interrupted early is no longer over-charged. ## Why boosting exists A fixed priority scheme has two well-known failures, and Windows patches both with temporary boosts within the dynamic range. **Latency after waiting.** A thread that just finished waiting has, by definition, not been using the CPU. On completion of an I/O the kernel applies a device-class-dependent boost so the thread that was waiting on disk or network gets back on a processor quickly rather than queueing behind CPU hogs. Similar boosts follow satisfaction of a wait on an event or semaphore, and a GUI thread whose window receives input gets both a priority boost and a longer quantum so typing and clicking feel immediate. **Starvation and priority inversion.** If a low-priority thread holds a lock that a high-priority thread needs, and a medium-priority thread monopolises the CPU, the low-priority holder may never run and the high-priority thread is blocked indefinitely. Windows does not implement priority inheritance for user-mode locks. Instead the balance set manager periodically scans the ready queues, and any thread that has been ready but not running for several seconds is lifted to priority 15 and given an extended quantum — usually long enough to release whatever it holds. It is a blunt, empirical anti-starvation device, not a real-time guarantee. After a boost, priority decays by one level at the end of each quantum the thread completes until it is back at base. It never decays below base. Real-time threads are excluded from every part of this: no boost, no decay. Boosting can be switched off per-thread or per-process with `SetThreadPriorityBoost` / `SetProcessPriorityBoost` — occasionally useful for measurement, rarely useful in production. ## What priority cannot do Priority decides *who wins contention*, never *how fast a thread runs*. Raising priority on a machine that is not CPU-saturated changes nothing; on a saturated machine it improves one workload strictly by delaying another. Reaching for `HIGH_PRIORITY_CLASS` to fix latency is almost always the wrong lever — the usual real causes are lock contention, synchronous I/O on a thread that should be async, or too few threads for the offered work.
- Why is REALTIME_PRIORITY_CLASS considered dangerous?Threads at 16-31 are never boosted, never decayed and always preempt everything in the dynamic range. A busy real-time thread can starve system threads that handle input, paging and device work, so the machine appears hung rather than merely slow. Windows gates it behind the *Increase scheduling priority* privilege, and almost every problem people reach for it to solve is really lock contention or synchronous I/O.
- Windows has no priority inheritance for user-mode locks — so how does it survive priority inversion?With the balance set manager's anti-starvation sweep: any thread ready but not scheduled for several seconds is temporarily lifted to priority 15 with an extended quantum, which is usually enough for a blocked lock holder to release the lock. It is empirical rather than a guarantee — good enough for general-purpose workloads, not a substitute for real-time design.
- Why can identical code feel more responsive on a Windows client than on Windows Server?Quantum policy differs. Client Windows uses short quanta and lengthens the quantum for threads of the foreground process, favouring interactive latency; Server uses long, uniform quanta, favouring throughput and consistent service behaviour. The `Win32PrioritySeparation` value under the `PriorityControl` key selects the policy, which is the "programs versus background services" setting.
saying these in an interview costs you the question
- Saying higher priority makes a thread run faster
- Believing Windows schedules processes rather than threads
- Thinking real-time threads also receive priority boosts
- Assuming Windows uses priority inheritance on locks
- Treating the priority class as independent of thread priority