Are interrupts used to signify that output is ready or input has completed?

Question

Operating System Concepts says:

During I/O, the various device controllers raise interrupts when they are ready for service. These interrupts signify

• that output has completed, or
• that input data are available, or
• that a failure has been detected.

Are interrupts used to signify that output is ready or input has completed?

If not, do they need to be signified by some other way?

Thanks.

Answer 1

Devices can use interrupts to signal all kinds of events. In fact, any change of state of the device or the device controller could be reported to the host CPU via an interrupt. It's all up to the designers of the device hardware and firmware.

(And, one would hope, they will at least ask the opinion of the poor schmuck who's going to have to write the driver. Far too many devices have been designed without such input, necessitating awkward, inefficient driver designs. In fact there have been cases where some of a device's capabilities were unable to be used to their fullest because the device's host interface - which includes, but is not limited to, the interrupt structure - was designed without awareness of what could and couldn't be done in the driver. But I digress.)

The material you quoted is correct as far as it goes, but it seems to me to be a very simplistic view.

I'm not sure how "output is ready" is different from "output is completed". (Ready to be picked up from the printer output tray?) Similarly, "input data available" and "input completed" sound to me to be pretty close to the same thing. They would probably, however, imply different required work on the part of the driver. To me, "input completed" would mean the incoming data is in the host memory and a local thread's I/O operation can be completed, while "input data available" would probably mean that the driver would still need to move it from the device's interface to an in-memory buffer.

But this is just semantics. As a driver writer you have to read the device host interface specs carefully to find out what's really meant by any given interrupt, and what you're supposed to do about it. Sometimes you even need to read the firmware code or study the logic diagram. (Is that an edge- or level-triggered flip-flop? The device engineers sometimes have the oddest notions! But I digress again...)

For a slightly more complex example, consider a communications interface with a FIFO. We generally want to avoid excessive interrupts to the host; for example, an interrupt per packet is likely too many. So our device might allow us to tell it about a series of buffers to be transmitted via a "FIFO" (first-in, first-out") interface, and the device will take care of moving them all out on the wire.

But we don't necessarily want an interrupt only when all of the buffers are done! It would be better if we were notified when, say, the buffer was down to just 20% or 10% full. When we get such an interrupt we'll put more buffers in the FIFO (stopping when it's full, of course). If we only got an interrupt when the FIFO was empty, there would be a slight delay before we could get the next buffer to it for transmission, thus reducing throughput. By giving us an interrupt when the FIFO is "about to be" empty we can eliminate that delay.

Answer 2

At their most basic level, interrupts are used to convey a very simple "hey! check on me" message from one thing to another...

They can be both hardware (e.g: a voltage indicates state), or software (e.g: a user presses Ctrl + C).

Some interrupts are really important and must be serviced right away, while others are less important and might not be serviced for some time.

It's impossible to list all of the uses of interrupts, in part because new technology brings new features and most likely new reasons for interrupts.

---

Within an Integrated Circuit, it's often possible to have interrupts with quite specific meanings, for example:

• UARTs (i.e: Serial Ports)
  • Frame has been received - this can mean that the host must now take that frame's payload from the peripheral's register and store it before another frame arrives, overwriting the first.
  • Frame has been sent - this can mean that the host is now free to submit new data into the peripheral's register, causing another frame to be transmitted
• Timers
  • PWM
    • The counter has wrapped or reached its upper limit - used to reset a PWM signal
    • The counter has reached its compare value - used to set a PWM signal
  • Scheduling - Used to preempt a running task, and schedule another
• Divide by Zero - Something tried to make the universe implode, and was stopped... This interrupt allows some tidy-up or remedial action (e.g: termination of an application).

---

When discreet (separate) components need to communicate, then an interrupt can require some interaction to decipher - mainly because of the number of interconnects and I/O pins that would be required otherwise. For example:

• A real-time clock - On receipt of the interrupt, the host will interrogate one of it's registers, and might determine that "Alarm 2" has been triggered. The result of this depends on the system.
• A sound card
  • The sound card might have a buffer allowing the host to produce blocks of audio that the card will play out unattended. If this buffer runs low, then the host must provide more data, otherwise the buffer will underrun (run out)...
  • If the interrupt is not serviced in time, then you might hear a repeating snippet of audio, as demonstrated here by a forced system crash

---

Interrupts can often be ignored by software, and instead handled by a Direct Memory Access module. With DMA, the software can disregard the low-level handling of hardware - for example being notified when a whole packet has arrived, instead of each symbol.