Chapter 28. Interrupts

You're familiar with interruptions already; you get them every day ” a request for something special, right now. You might possibly delay it by locking your door, but the sources rarely go away, and you'll have to take care of it sooner or later.

A computer interrupt is the same thing: something out there wants immediate attention. This request appears as a hardware signal delivered to the CPU. Each interrupt has with it a priority, relating to how soon the system should take care of the situation. Some interrupts are more like completion signals: "The task you gave me is finished, and I'm waiting for something else to do. " This case is not a high priority, since neglecting it for a while won't hurt anything (except perhaps performance). Other interrupts are more time-critical: a clock tick, for instance, won't wait for too long. Eventually the clock will request another interrupt as time passes . Miss too many of these and your system's notion of the time of day will be seriously off. Another example might be incoming data, which signals its arrival. Wait too long and it may be overwritten by new data ” and you've lost it.

All of these situations require the CPU to stop what it's doing (eventually) and go off to execute some unique code that handles this special condition. This code is known as an interrupt service routine , and there is usually a separate routine for each possible interrupt that might occur. Since each interrupt has an associated priority, the system will normally associate the same priority with the service routine. This prevents lower-priority requests from interrupting a high-priority service function.

An interrupt is generally known as an asynchronous event , since it can occur at any time unrelated to the current code being executed by the machine. The CPU will check before fetching the next instruction to see if an interrupt has been requested and if it is at a high enough priority to be recognized. If the interrupt needs to be handled, the system will immediately perform some sort of function call or trap to the appropriate kernel code. As a part of this unexpected break in the normal flow of events (and code), the CPU must ensure that no state information is ever lost: the interrupted code must be able to pick up and continue exactly where it left off, as if nothing had ever happened .