Coursify

Interrupt-Initiated I/O: Meaning, Mechanism, and OS/Hardware Workflow

Interrupt-Initiated I/O: Meaning, Mechanism, and OS/Hardware Workflow

Verified Sources
Nov 4, 2026

Interrupt-initiated I/O (often phrased as interrupt-driven I/O) is an input/output design where an I/O device requests CPU attention by raising an interrupt, instead of the CPU continuously checking (polling) for device readiness. When the interrupt occurs, the interrupt handler runs, performs the necessary I/O bookkeeping (e.g., reading received data or acknowledging transmission), and then returns control to the interrupted program or scheduler.

In a typical system, the CPU executes normal code while devices operate in the background. When a device completes an event (e.g., “receive buffer full”, “transmit buffer empty”), it triggers an interrupt line. The CPU:

  1. suspends the current instruction stream (logically),
  2. vectors to the appropriate interrupt service routine (ISR),
  3. transfers/acknowledges data with the device registers,
  4. possibly schedules follow-up work for a driver or thread.

This approach reduces wasted CPU cycles versus polling and allows faster response to device events.2

Core terms

  • Interrupt
  • Interrupt handler (ISR)
  • I/O device readiness
  • Polling
  • Device driver

Footnotes

  1. Interrupt — Wikipedia (https://en.wikipedia.org/wiki/Interrupt) - Overview of interrupts and interrupt handlers as control transfers to service routines. ↩ ↩2

  2. Input/output (computing) — Wikipedia (https://en.wikipedia.org/wiki/Input/output) - General background on how I/O is managed, including OS/CPU interaction patterns. ↩

Interrupt-driven I/O & ISR overview (educational)

Why interrupts improve I/O efficiency

With polling, the CPU must repeatedly read device status registers until the device is ready, which can burn CPU time—especially when events are infrequent or have long waits. In interrupt-initiated I/O, the CPU instead waits for an event; only when the device signals via interrupt does the CPU spend time handling the event.2

A useful way to think about it:

  • Polling: “Is the device ready yet?” repeated many times.
  • Interrupt-driven: “I’ll keep running; when the device is ready, it will tell me.”

Footnotes

  1. Interrupt — Wikipedia (https://en.wikipedia.org/wiki/Interrupt) - Overview of interrupts and interrupt handlers as control transfers to service routines. ↩

  2. Input/output (computing) — Wikipedia (https://en.wikipedia.org/wiki/Input/output) - General background on how I/O is managed, including OS/CPU interaction patterns. ↩

How interrupt-initiated I/O works (high-level sequence)

  1. 1
    Step 1

    The OS/driver configures device registers (e.g., start receive/send) and enables the device’s interrupt source.

  2. 2
    Step 2

    The device hardware progresses (e.g., collects incoming bytes into a buffer, or empties a transmit FIFO).

  3. 3
    Step 3

    Typical events include completion, buffer full/empty, error conditions, or status changes.

  4. 4
    Step 4

    The CPU stops the current flow and jumps to the interrupt handler entry point (interrupt vector).

  5. 5
    Step 5

    The ISR reads/writes the device registers/buffers and acknowledges the interrupt to prevent re-triggering.

  6. 6
    Step 6

    For longer processing, the ISR may defer work (e.g., wake a waiting thread or schedule a bottom half/tasklet).

  7. 7
    Step 7

    After return from interrupt, execution continues at the previously interrupted point (or context switches if necessary).

Hardware and OS responsibilities

Interrupt-initiated I/O is a co-design between hardware and the operating system:

  • Hardware responsibilities

    • Detect device events (data ready, transmit complete).
    • Assert an interrupt request line and provide identification (interrupt number/vector).
    • Maintain status registers and buffers for the ISR to consult.

  • OS/driver responsibilities

    • Register the ISR for a specific interrupt source.
    • In the ISR: acknowledge/clear the interrupt, move data between device and memory, handle error flags.
    • In deferred contexts: perform higher-level processing (parsing, copying to user buffers, waking processes).

This mapping is consistent with how interrupt controllers and ISRs are described in systems and architecture references.2

Footnotes

  1. Interrupt — Wikipedia (https://en.wikipedia.org/wiki/Interrupt) - Overview of interrupts and interrupt handlers as control transfers to service routines. ↩

  2. Input/output (computing) — Wikipedia (https://en.wikipedia.org/wiki/Input/output) - General background on how I/O is managed, including OS/CPU interaction patterns. ↩

Interrupt-initiated I/O is “event-driven,” not “always checking”

Think of it as the device pushing state changes to the CPU via interrupts, instead of the CPU repeatedly polling readiness.

Be careful: ISR should be short

ISRs run with restricted scheduling/latency constraints; long work should be deferred to avoid blocking other interrupts and harming real-time responsiveness.

Relation to DMA and why interrupts still matter

Often, high-throughput I/O uses DMA (Direct Memory Access) to move bulk data without the CPU copying every byte. Even with DMA, interrupt-initiated signaling remains important:

  • DMA completion or error can trigger an interrupt.
  • The CPU then performs final bookkeeping (update descriptors, notify waiting threads, start next transfer).

So interrupts can be:

  • the primary mechanism for small/medium I/O events, or
  • a completion/event notification mechanism even when DMA is used.2

Key comparison: polling vs interrupt-initiated vs DMA+interrupt

ApproachCPU behaviorTypical use casePerformance profile
PollingRepeatedly checks device statusVery simple devices, low event ratesCPU wastes cycles; higher latency variability
Interrupt-initiated I/OCPU reacts only when device interruptsKeyboard, network RX/TX completions, serial I/OLow CPU waste; fast event handling
DMA + interruptCPU sets up DMA; interrupt signals completionBulk transfers (disk, NIC large packets)High throughput; CPU overhead reduced to event handling

(Interrupt-initiated I/O is the common underlying control-flow idea across these designs.)3

Footnotes

  1. Input/output (computing) — Wikipedia (https://en.wikipedia.org/wiki/Input/output) - General background on how I/O is managed, including OS/CPU interaction patterns. ↩ ↩2

  2. Direct memory access (DMA) — Wikipedia (https://en.wikipedia.org/wiki/Direct_memory_access) - Explains DMA and common usage patterns where interrupts can indicate completion/errors. ↩ ↩2

  3. Interrupt — Wikipedia (https://en.wikipedia.org/wiki/Interrupt) - Overview of interrupts and interrupt handlers as control transfers to service routines. ↩

From initiation to completion in interrupt-driven I/O

Driver starts I/O

1. Initiate

Driver writes device registers; enables interrupt source."

Device works

2. Operate

Hardware buffers data or performs transfer."

Interrupt raised

3. Signal

Device/event controller asserts interrupt to CPU."

ISR runs

4. Service

Acknowledge/clear interrupt; move data to memory."

Deferred processing / wake-up

5. Notify

Driver completes higher-level work; wakes waiting tasks."

Common confusions and edge cases

Interrupt-initiated I/O Quick Deck

1 / 4
Question · Term

What does “interrupt-initiated I/O” mean?

Click to reveal
Answer · Definition

I/O where the device signals the CPU via interrupts when it is ready or when an I/O event completes, instead of the CPU polling continuously.

Knowledge Check

Question 1 of 4
Q1Single choice

In interrupt-initiated I/O, what primarily triggers CPU attention for an I/O event?

Explore Related Topics

1

IO Device Interfaces: Short Notes (Two Topics)

2

Input/Output Transfers: DMA and Data Movement Mechanisms

3

Daisy-Chain Priority Interrupts: Detailed Mechanism, Timing, and Design Trade-offs

Browse all research articles