Section 7: CPU Interrupts and Context Switching

The Big Picture: Tap on the Shoulder, and Taking Turns

This section covers two linked ideas. Interrupts are how the CPU gets told "something urgent happened". Context switching is how one core juggles many programs by taking turns. (Chapter 4 shows the hardware side of interrupts. Here we look at what the CPU itself does.)

7.1 What Is an Interrupt?

What it is: A signal that tells the CPU to stop what it is doing right now, deal with something urgent, and then come back to exactly where it left off.

Without interrupts the CPU would have to keep asking, in a loop, "Has a key been pressed? Has the network card received anything? Is the disk read finished?" That wastes huge amounts of time just checking. This approach is called polling. Interrupts flip it around: devices tell the CPU only when something really happens. It is like cooking while waiting for the doorbell, instead of walking to the door every ten seconds.

CPU executing normal instructions...
   [instr][instr][instr] ⚡INTERRUPT⚡ [handler runs] [instr][instr]...
                              │
                    CPU saves its current state,
                    jumps to a handler, deals with
                    the event, then resumes exactly
                    where it left off

7.2 Hardware Interrupts

What they are: Signals sent by physical devices to report that something happened.

Examples:

• A key is pressed on the keyboard
• A network packet arrives at the NIC (network interface card)
• A disk finishes a read or write
• A timer chip fires (it gives the OS scheduler a regular "heartbeat")

Each device is wired (physically, or through message-signaled interrupts on PCIe, see Chapter 4) to an interrupt controller. That controller sorts out priorities and delivers the signals to the CPU. When one fires, the CPU pauses its current instructions and jumps to a handler routine (a small piece of code written for that interrupt).

7.3 Software Interrupts (System Calls)

What they are: Interrupts that are deliberately triggered by code instead of by a physical device. This is the mechanism behind the system calls in Section 6.4.

When an app runs a SYSCALL instruction, the hardware treats it as a controlled software interrupt. Execution is sent into the kernel at a fixed, predefined entry point, the privilege level switches to Ring 0, and the kernel handles the request.

7.4 Exceptions and Faults

What they are: A special kind of interrupt created by the CPU itself when something goes wrong while running an instruction. It does not come from an outside device. It comes from the instruction stream.

Common examples:

What happens next: The CPU hands control to the kernel's exception handler. Depending on the exception, the kernel may quietly fix things and resume the program (a page fault is often fixed without you noticing). Or it may have no way to recover and end the offending process. That is what produces the classic "Application has stopped working" dialog. If it happens inside the kernel itself, you get a Blue Screen of Death.

7.5 Context Switching (Process/Thread Switching)

What it is: Pausing one running thread and resuming a different one on the same core.

A core can truly run only one instruction stream at a time (ignoring SMT for now). So when you have more running programs than cores, the "all at once" feeling is an illusion. The CPU switches between them very quickly, often dozens or hundreds of times per second. It is like one waiter serving many tables, quickly and fairly.

Core 0 timeline:
[Chrome thread][Spotify thread][Chrome thread][Word thread][Chrome thread]...
       ▲               ▲               ▲
   context switch  context switch  context switch

A context switch is usually triggered by a timer interrupt (Section 7.2) telling the scheduler "this thread's time slice is up". It involves three steps:

1. Save the current thread's complete CPU state (all register values, the Program Counter, flags) into memory
2. Load the next thread's previously saved state back into the registers
3. Resume at exactly the instruction where that thread left off

From the thread's point of view it never stopped. It carries on as if no time had passed.

7.6 Context Switch Overhead

Switching is not free. Every switch costs something:

This is why the OS does not switch as fast as it possibly could. There is a deliberate trade-off (the time slice or quantum, covered in Chapter 10) between being responsive (switch often, so nothing feels stuck) and being efficient (switch rarely, so less time is wasted on switching). It is also why a system with far more runnable threads than cores (a "high context-switch rate", visible in Task Manager / Resource Monitor) can feel sluggish even when no single thread is doing much. The switching overhead adds up.

Summary