Interrupt-driven I/O — simultaneous requests In a priority-based interrupt system, if two or more devices assert interrupt requests at exactly the same time, which device will be serviced first?

Introduction / Context:
Interrupt-driven input/output (I/O) lets peripherals request attention from the processor without constant polling. When several devices assert interrupts at the same instant, the system must decide which one the CPU will service first. Understanding priority resolution is crucial for designing reliable embedded and computer systems.

Given Data / Assumptions:

• Multiple devices can request service concurrently.
• An interrupt controller or internal CPU logic arbitrates requests.
• Each interrupt source has an assigned priority level and possibly a vector.

Concept / Approach:
Most architectures use fixed or programmable priority schemes. A centralized interrupt controller (for example, a PIC) resolves simultaneous requests and forwards only the highest-priority request to the CPU. Lower-priority requests remain pending until the CPU completes the current service routine and re-enables interrupts or performs nested servicing according to policy.

Step-by-Step Solution:

Verification / Alternative check:
Datasheets for programmable interrupt controllers show priority rotation or fixed priority tables; simultaneous requests are deterministically resolved to one highest-priority source, confirming the behavior described.

Why Other Options Are Wrong:

• Closest to CPU / fastest device: physical proximity or intrinsic speed does not determine service order.
• System crash: robust designs explicitly arbitrate to prevent contention.
• Lowest vector ignored: vectors map handlers; they are not “ignored” by design.

Common Pitfalls:

• Forgetting that priority can be rotated or dynamically reprogrammed, which still deterministically selects one request first.

Final Answer:
the device assigned the highest priority is serviced first