Trap vs Interrupt: What Is the Difference?
Trap vs interrupt explained — synchronous vs asynchronous origins, shared dispatch, and examples — with OS interview questions answered.
Expected Interview Answer
A trap is a synchronous event deliberately raised by the currently executing instruction (such as a system call or a divide-by-zero error), while an interrupt is an asynchronous event raised by external hardware that can occur at any point regardless of what instruction is running.
A trap, sometimes called a software interrupt or exception, is triggered by the CPU itself as a direct, predictable consequence of executing a particular instruction — a program deliberately issues a `syscall`/`int` instruction to request a kernel service, or the ALU signals an error such as an invalid opcode or division by zero. Because it originates from the instruction stream, a trap always happens at the same point on re-execution and the CPU knows exactly which instruction caused it. An interrupt, by contrast, is generated by a device outside the CPU’s control flow — a keyboard controller, disk controller, or timer chip asserts an interrupt request line whenever it needs attention, with no relationship to what instruction the CPU happens to be executing at that moment. Both mechanisms ultimately do the same low-level thing: save the current execution context, look up a handler address in the interrupt/trap vector table, and transfer control to kernel-mode handler code, then return via a special instruction such as `iret`. The practical distinction interviewers probe for is synchronous-and-intentional (trap) versus asynchronous-and-external (interrupt), because that distinction drives how the OS reasons about reproducibility, priority, and nesting.
- Clarifies why system calls are traps, not interrupts
- Explains reproducibility: traps repeat, interrupt timing does not
- Grounds understanding of the shared trap/interrupt vector table
- Sets up correct reasoning about nested and masked interrupts
AI Mentor Explanation
A trap is like a batter deliberately signaling for a runner because of a mid-pitch injury cramp — it happens as a direct, predictable result of what the batter themselves just did, at an exact known point in the over. An interrupt is like the floodlights suddenly failing mid-delivery: it is caused by something entirely outside the players’ control and can strike at any ball, regardless of what shot is being played. Both stop play and hand control to the umpire (the handler) via the same signal system, but only one was caused by the action on the pitch itself.
Step-by-Step Explanation
Step 1
Trap origin
A running instruction deliberately raises a trap — a system call, or a CPU-detected error like divide-by-zero — synchronously as part of executing that instruction.
Step 2
Interrupt origin
An external device asserts an interrupt request line asynchronously, unrelated to whatever instruction the CPU is currently executing.
Step 3
Shared dispatch
Both save the current context and look up a handler address in the same vector table mechanism before transferring control to kernel mode.
Step 4
Return
The handler runs, then a return instruction restores the saved context — after the next instruction for a trap, or the interrupted instruction for most interrupts.
What Interviewer Expects
- Synchronous-and-intentional (trap) vs asynchronous-and-external (interrupt)
- A concrete example of each (system call trap; timer/device interrupt)
- Awareness that both share the vector-table dispatch mechanism
- Understanding that traps are reproducible on re-execution, interrupt timing is not
Common Mistakes
- Calling every trap-and-interrupt event generically “an interrupt”
- Thinking a system call is an interrupt rather than a trap
- Believing traps are unpredictable like hardware interrupts
- Not knowing both use the same vector table dispatch structure
Best Answer (HR Friendly)
“A trap is something the currently running program causes on purpose or as a direct side effect, like asking the OS for a service or hitting a math error, so it always happens at the same predictable point. An interrupt is something external, like a keyboard press or a timer, that can happen at any moment no matter what the program is doing. Both hand control over to the operating system in the same underlying way, but one is self-inflicted and repeatable, the other is not.”
Code Example
/* Trap: synchronous, caused by the running instruction itself */
long syscall_trap(long syscall_no, long arg) {
/* user code executes: int 0x80 (or syscall) */
/* CPU saves context, jumps to trap_vector[syscall_no] */
return dispatch_syscall_table[syscall_no](arg);
}
/* Interrupt: asynchronous, caused by an external device */
void timer_interrupt_handler(void) {
/* fires whenever the timer chip asserts IRQ0, regardless
of which instruction the CPU was executing */
save_context();
scheduler_tick();
restore_context();
}
/* Both use the same underlying dispatch table */
void (*interrupt_vector_table[256])(void) = {
[0x00] = divide_by_zero_trap, /* CPU-detected trap */
[0x20] = timer_interrupt_handler, /* hardware IRQ */
[0x80] = syscall_trap_entry, /* software trap */
};Follow-up Questions
- Why is a system call implemented as a trap rather than a function call?
- What happens if an interrupt arrives while a trap handler is running?
- How does the CPU distinguish which trap or interrupt occurred?
- What is the difference between a fault, a trap, and an abort?
MCQ Practice
1. Which of these is a trap rather than a hardware interrupt?
A system call instruction is a synchronous, self-triggered trap; the other three are asynchronous hardware interrupts.
2. What best characterizes an interrupt compared to a trap?
Interrupts are raised by external hardware and can occur regardless of the instruction currently executing, unlike synchronous traps.
3. What do traps and interrupts have in common at the dispatch level?
Despite differing origins, both mechanisms save context and dispatch to a handler using the same vector table structure.
Flash Cards
Trap vs interrupt in one line? — Trap: synchronous, self-triggered by the running instruction. Interrupt: asynchronous, triggered by external hardware.
Is a system call a trap or interrupt? — A trap — it is deliberately raised by the executing program.
What do they share mechanically? — Both save context and dispatch through the same vector table to a handler.
Which one is reproducible on re-execution? — The trap — it happens at the same point every time; interrupt timing varies.