interrupt latency (and determinism)
When a fire alarm goes off, what matters is not just that someone eventually responds, but how QUICKLY the response begins — the gap between the alarm sounding and the firefighter actually starting to act. Interrupt latency is that gap for a processor: the time from when an interrupt signal is raised by hardware until the first useful instruction of the corresponding interrupt service routine actually executes.
Several things fill that gap, and a careful engineer accounts for each. First, the CPU may need to finish (or abandon) the current instruction. Second, and often the biggest contributor, interrupts may be temporarily DISABLED — if your code is inside a critical section with interrupts masked, the new interrupt waits until they are re-enabled, so the longest stretch with interrupts off sets a floor on worst-case latency. Third, a higher-priority interrupt already being serviced may delay a lower-priority one. Fourth, the hardware spends a fixed number of cycles saving context and fetching the handler address from the vector table (on Cortex-M this is a small, fixed, deterministic number, around a dozen cycles). Closely tied to latency is determinism: a system is deterministic if its timing is predictable and bounded — the same situation always takes a knowable, capped amount of time. Determinism, not raw speed, is what lets you guarantee a deadline. A fast processor with unpredictable latency (because of caches, an OS, or long interrupt-disabled regions) can be WORSE for real-time work than a slower but perfectly predictable one.
It matters because for hard real-time systems the WORST-CASE interrupt latency, not the average, decides whether a deadline can be met — you must bound it. The honest, practical points: the single most controllable cause of latency is how long YOU keep interrupts disabled, so keep critical sections and the highest-priority ISRs short. Caches, branch prediction, and an operating system all introduce variability that hurts determinism, which is one reason simple bare-metal MCUs can give tighter latency guarantees than a fast application processor running Linux. And 'average latency' is a comforting but dangerous number for safety-critical timing — you must reason about the worst case.
Worst-case interrupt latency ~= longest time interrupts are OFF + higher-priority ISR still running + fixed hardware entry cost (~12 cycles) + ISR prologue to first useful instruction. // The part YOU control most: shrink the longest 'interrupts disabled' // critical section. A 50-us masked section means >= 50 us worst case.
Worst-case latency is dominated by the longest interrupts-disabled region — the part you most directly control. Average latency is not enough for hard real-time.
For real-time work it's WORST-CASE latency that matters, not average — and the biggest controllable cause is how long you keep interrupts disabled. Caches and an OS add variability, so a fast Linux box can have worse worst-case latency than a slow MCU.