Interrupt-Driven I/O

Introduction

Interrupt-driven I/O solves the busy-wait problem of programmed I/O. Instead of the CPU repeatedly polling the device status, the device interrupts the CPU when it's ready — like a doorbell instead of constantly checking if someone's at the door. The CPU can do useful work and only handles the device when attention is actually needed. This dramatically improves CPU utilization and enables multitasking.

How Interrupts Work

1. CPU initiates I/O operation (writes command to device)
2. CPU continues executing OTHER instructions (not waiting!)
3. When device is ready, it asserts its interrupt request line
4. CPU detects the interrupt between instructions
5. CPU saves current state (PC, registers, flags)
6. CPU jumps to the Interrupt Service Routine (ISR) for that device
7. ISR handles the data transfer
8. ISR restores state and returns (IRET instruction)
9. CPU resumes what it was doing before the interrupt

Interrupt Handling Steps (Detailed)

1. Interrupt Request

Device asserts its IRQ (Interrupt Request) signal

2. Interrupt Acknowledgment

CPU finishes current instruction, then checks for pending interrupts

3. Context Save

4. Identify Interrupt Source

Methods:

• Polling: CPU checks each device (simple but slow)
• Vectored: Device provides an interrupt vector number → index into Interrupt Vector Table
• Daisy-chain: Priority-ordered chain of devices; closest device responds first

5. Execute ISR

6. Restore Context and Resume

Interrupt Vector Table

A table in memory mapping interrupt numbers to ISR addresses:

When interrupt vector 1 arrives, CPU jumps to address 0x00002000.

Interrupt Priority

What if multiple devices interrupt simultaneously? Priority determines which gets serviced first:

Priority Schemes

• Fixed priority: Hardware assigns fixed levels (timer > keyboard > disk)
• Programmable priority: Software can change priorities
• Rotating priority: Prevents starvation of low-priority devices

Nested Interrupts

Higher-priority interrupts can interrupt lower-priority ISRs:

Advantages over Programmed I/O

Disadvantages

• Interrupt overhead: Context save/restore takes 50-500 cycles per interrupt
• Still CPU-involved for every byte/word transferred
• Not efficient for bulk data transfers (each word = one interrupt)
• For moving 1 MB at 4 bytes/interrupt = 250,000 interrupts → significant overhead

This limitation motivates DMA (Direct Memory Access) for bulk transfers.

Key Takeaways

1. Interrupts allow the CPU to do useful work while waiting for I/O devices
2. The device signals the CPU when ready — no polling needed
3. The CPU saves state, executes an ISR, then resumes the interrupted program
4. Vectored interrupts use a table to quickly locate the correct ISR
5. Priority schemes handle simultaneous interrupts from multiple devices
6. Interrupts are efficient for low-frequency events but costly for bulk data (use DMA instead)
7. Interrupt-driven I/O is the foundation of modern multitasking operating systems

Real-World Examples of Interrupt-Driven I/O

Keyboard Input: When you press a key, the keyboard controller sends an interrupt to the CPU. The ISR reads the key code from the keyboard buffer, translates it to a character, and places it in the input queue for the application. Between keystrokes, the CPU is free to run other programs — this is why you can type while your computer performs background tasks.

Network Card: When a network packet arrives, the NIC (Network Interface Card) triggers an interrupt. The ISR copies the packet from the NIC buffer to system memory and signals the network stack to process it. Without interrupts, the OS would need to constantly poll the network card, wasting enormous CPU cycles on most checks that find nothing.

Timer Interrupts: The system timer generates periodic interrupts (typically every 1-10 ms). The OS uses these for process scheduling — when a timer interrupt fires, the scheduler can preempt the current process and switch to another. This is the foundation of preemptive multitasking in modern operating systems.

Interrupt Latency and Performance Considerations

Interrupt latency is the time between when a device asserts an interrupt and when the ISR begins executing. It includes:

• Recognition time: CPU finishes current instruction and acknowledges the interrupt
• Context save time: Pushing registers onto the stack
• Vector lookup time: Finding the correct ISR address
• Pipeline flush: Clearing any prefetched instructions

In real-time systems, interrupt latency must be bounded and predictable. Hard real-time systems (medical devices, industrial controllers) require worst-case latency guarantees, often in the microsecond range. Techniques to minimize latency include keeping ISRs short, disabling interrupts for minimal durations, and using dedicated interrupt controllers with hardware priority resolution.

Common Interview Mistakes to Avoid

• Do not confuse interrupt-driven I/O with DMA — in interrupt-driven I/O, the CPU still transfers each byte/word manually
• Remember that ISRs should be as short as possible to avoid blocking other interrupts
• Understand that maskable interrupts can be disabled by software, while non-maskable interrupts (NMI) cannot