Polled Waiting Vs Interrupt Driven

Real-time systems are said to be “event-driven”, meaning that a primary function of the system is to respond to “events” that occur in the system’s environment. How does the program detect an event happening? There are two fundamental approaches:

Polled Waiting

The program begins with some initialization and then enters an infinite loop that tests each possible event to which the system must respond. For each event that is set, the program invokes the appropriate servicing function.

int main (void)
    while (TRUE)
        if (event_1)
        if (event_2)
        // ........
        if (event_n)

When to use

  • Fast device: for devices which input or output data in very fast speed, it won't execute useless loops for many times, so won't introduce much overhead. However, if we use interrupt driven IO, the overall overhead generated by dealing with interrupts may be very high.
  • Periodic device: we can let the task which run the polled waiting loop sleep for a period of time, and wake up it when the data is about ready.


  • The response time to an event varies widely depending on where in the loop the program is when the event occurs. For example, if event_1 occurs immediately before the if (event_1) statement is executed, the response time is very short. However if it occurs immediately after the test, the program must go through the entire loop before servicing event_1.
  • For slow device, introduce huge overhead because of busy waiting.
  • All events are treated as having equal priority (If all event are tested in the same process).
  • As new features, hence new events are added to the system, the loop gets longer and so does the response time.
  • The response time is also a function of how many events happen to be set at the same time and consequently get serviced in the same pass through the loop.

Interrupt Driven

When to use

  • Slow and Non-periodic device: for this kind of device, interrupt driven IO can achieve much higher performance than polled waiting.
  • Device requires guaranteed short latency: since polled waiting IO introduce various latency.


  • It has large overhead/byte, therefore low transfer rate when transmits one or few bytes of data per interrupt. It needs to 1. push program counter, flag register. 2. read interrupt type code, access interrupt vector table, load address of ISR. 3. after that, it might need to push values of all register that will be used in the ISR. 4. when the ISR return, CPU need to restore it previous status by popping values from stack to registers.
  • According to the above reason, for device which has high speed, the overhead introduced by interrupt driven IO will be significant.
  • Increase complexity, and introduce problem of synchronization.



Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License