Introduction
Traps, interrupts, and exceptions are different ways control reaches the operating system kernel. They matter because user mode is restricted, kernel mode is privileged, and the CPU needs controlled paths for entering OS handling.
The difference depends on what caused the event and when it happened. A program may request a service, hardware may signal the CPU, or the current instruction may create a fault that needs OS attention.
Why These Events Are Needed
User programs cannot directly access protected memory, devices, disk control, or kernel data structures. Still, programs and hardware often need the operating system to respond.
These kernel-entry events solve three different needs:
System calls need controlled entry: A user program must be able to intentionally request an OS service.
Devices need attention: Hardware must be able to notify the CPU when something happens.
Faults need safe handling: If an instruction causes an error or missing-page condition, the OS must decide what to do.
Trap, Interrupt and Exception
Although these terms are related, they should not be treated as identical. The clean way to separate them is by source and timing.
Event | Main Cause | Timing | Common Example |
|---|---|---|---|
Trap | Intentional request from current program | Synchronous | System call |
Interrupt | External hardware or device signal | Asynchronous | Timer, keyboard, disk, network interrupt |
Exception | Condition caused by current instruction | Synchronous | Page fault, divide by zero, illegal instruction |
A trap is commonly used when a program deliberately enters the kernel, such as during a system call. An interrupt usually comes from outside the current instruction stream. An exception is caused by the instruction currently being executed.
Trap, Interrupt and Exception
Synchronous vs Asynchronous Events
A synchronous event has a direct relationship with the current instruction stream. It happens because the running code executed something specific.
Examples include:
System call trap: The program intentionally requests kernel service.
Page fault: The current instruction accesses a page that is not currently available in physical memory.
Divide by zero: The current instruction performs an invalid arithmetic operation.
An asynchronous event comes from outside the current instruction stream. A timer interrupt, keyboard input, disk completion, or network packet can arrive according to hardware timing, not because the current instruction directly caused it.
How Kernel Handling Works
When a trap, interrupt, or exception occurs, the CPU must preserve enough state to let the OS handle the event safely. After that, control moves to the correct kernel handler.
The basic flow is:
Event occurs: A system call, hardware signal, or fault needs OS attention.
CPU saves state: Enough context is saved so execution can resume if appropriate.
Kernel handler runs: Control moves to the proper OS handler.
Cause is identified: The kernel checks whether it is handling a system call, interrupt, page fault, or another event.
OS handles it: The kernel performs the required work.
Next action is chosen: The process may continue, terminate, or the scheduler may run another task.
This mechanism keeps kernel entry controlled instead of allowing user code to jump freely into privileged OS code.
How Kernel Handling Works
Common Examples
A system call is a common trap example. A program may call read() or write(), the wrapper prepares the request, and a controlled trap enters the kernel so the OS can perform the service.
A timer interrupt is a common interrupt example. When the timer fires, the CPU enters the kernel's timer handler. The OS may then continue the same process or switch to another process.
A page fault is a common exception example. If the page can be brought into memory, the process may continue. If the access is invalid, the OS may terminate the process.
Common Confusions
A trap is not always an error. In system calls, a trap is a normal and intentional way for a user program to request kernel service.
An interrupt and an exception are also not the same. An interrupt usually comes from hardware or an external event, while an exception is tied to the current instruction.
A page fault is not always a programming bug. In virtual memory, page faults can occur normally when the OS needs to bring a required page into physical memory.
Summary
Traps, interrupts, and exceptions are controlled ways to enter kernel handling. A trap is usually intentional and synchronous, an interrupt is usually asynchronous and external, and an exception is synchronous and caused by the current instruction.
The main question is always: what caused the event, and did it come from the current instruction stream? That one distinction makes the difference between system-call traps, hardware interrupts, and instruction-caused exceptions much clearer.
Be the first to add a comment.