View source for Interrupt Service Routine

{{DISPLAYTITLE:Interrupt Service Routines (ISRs)}}<!--
-->{{#set: Priority=3 | Summary=A procedure (or “method”) called by the <i>hardware</i> 'behind the scenes'.  User applications are not directly aware of these.}}<!--
-->{{#invoke:Dependencies|add|Interrupts,5|Queues,3}}
When an [[Interrupts|interrupt]] is taken the affected processor stops what it was doing and (effectively) performs an [[Exceptions|exception]] entry – similar to a system call.  The processor then needs to determine the source of the interrupt and perform the relevant service before returning.  It must be able to return <em>as if it had never been away</em> so it must not irretrievably alter the interrupt process’ context.

Exactly what occurs when an interrupt is taken depends on the [[Extra:ISA|particular processor]] but, in general, it will have saved a return address and any <em>mode</em> information which was changed (did it interrupt a user or kernel mode process, for example) but, often little else.  The processor is <em>in principle</em> switching into a different [[context]] to process the interrupt; <em>in practice</em> a complete context switch (and another, back) are too expensive. Usually just a subset of the processor’s internal (register) state is saved to give a small amount of working room.
<blockquote>
<strong>Note</strong>: if the interrupt service routine is written in a compiled language (likely to be C) the compiler needs to know that this is interrupt code so that it does not, inadvertently, change some state which it shouldn’t.  This may involve saving “all” the processor state although the loading of a new context and changing page tables et alia can still be avoided.
</blockquote>

=== Determining the interrupt source ===
There are usually more potential sources of interrupts than there is provision for on a particular processor.  (ARM, for example, has two hardware interrupt inputs.)  Therefore several (or “many”) inputs are logical-OR-ed together.  The first issue is to sort out the particular interrupt to service.
<blockquote>
Bear in mind that more than one interrupt may activate at the same time.
</blockquote>
There are typically two ways of choosing an interrupt: many complex systems use a combination of both.

==== Hardware ====
A [[Interrupt_Controller|hardware interrupt controller]] can decide and provide a <strong>vector</strong> to the relevant service routine.  The <em>vector</em> is a <em>pointer</em> to the code which has been determined and pre-programmed at initialisation.  The controller can choose the highest (also pre-programmed) priority active interrupt and provide the appropriate vector; this means the processor can get to the relevant code quickly. The dialogue goes something like this:

Interrupt controller: Oi!  I’ve got an interrupt.

Processor: Okay, I’ll take it.  What is it?

Interrupt controller: Go to address <[http://www.amc.com/shows/halt-and-catch-fire/exclusives/colossal-cave-adventure <em>xyzzy</em>]>.

This can sort out the interrupts which need the lowest <strong>latency</strong> (fastest response) and get to the relevant code very quickly.

==== Software ====
There may not be a hardware controller or the controller may not be capable of holding vectors for all the needed interrupts.  In this case the job is devolved to software.  The processor needs to read the potential interrupt sources until it finds the highest priority active source, then look up and jump to the associated address with a <code>switch</code>-like construct.  This is easily expandable but rather slower than using hardware assistance.  It is better used for the less frequent, latency-tolerant interrupt sources.

=== Interrupt priority ===
Interrupt priority can be determined in hardware or software.  Often it is not particularly important because interrupt service routines try to be short and fast and can get away with being [[Atomicity|atomic]].  Even then, priority may be relevant in choosing <em>which</em> of two or more active interrupts to service first.

A more sophisticated use of priority – relevant if there are some long, low-priority service routines – is in allowing one interrupt to pre-empt a running ISR.  This reduces the latency for the high priority interrupt at the cost of significantly more complexity. Practically, this requires hardware support from an interrupt controller which can track the current priority and temporarily disable any interrupt sources at or below the current service level.

Because interrupts can interrupt ISRs for interrupts which have interrupted other ISRs already – and must return appropriately – there needs to be a priority <em>stack</em> maintained; typically this is supported automatically in the interrupt controller hardware.

[[Image:nested_interrupts.png|link=|alt=Nested interrupts]]

=== Returning ===
When an ISR is finished it needs to restore the processor to the state it was in at the start, so the interrupted process doesn’t know it was there.  It then returns.  If interrupts have been ‘nested’ (as in the example above) then it <em>must</em> tell the controller that the current ISR is finished so the controller hardware can unstack and re-enable things appropriately.
----

=== Interrupt applications ===
Interrupts are used for many purposes but here are a couple of common classes.

==== Timer interrupts ====
A regular timer interrupt can be used to maintain a system clock; this, in turn can provide functions such as:

*waking [[Sleep|sleeping]] processes at the correct time.
*scheduling regular I/O routines.
** e.g. a keyboard is scanned at regular intervals which, by nature, can be several milliseconds apart.  An interrupt can cause this to happen whilst the processor can spend most of its time elsewhere.

==== I/O transfers ====
Many I/O operations are [[streams]] of bytes or blocks; these are typically [[Queues|queued]] in software.

*Data arrival times are probably uncertain.  When data arrives it can cause an interrupt which can insert the data into an <strong>input</strong> queue.  The ISR can then complete and the data can be removed as it is needed by the application.
*Conversely, the <strong>output</strong> capacity may be inadequate for an application.  Rather than slowing down, the application can output into a queue; as the output becomes available, the ISR can transfer data out of the queue: this is transparent to the application.

<!-- ** TODO ** Opportunity for an interactive demo. or two??? ** -->
==== Unexpected events ====
Example: a [[Extra:USB|USB]] device is inserted.  The interface will (probably) interrupt to signal the fact and the relevant installation can be scheduled.  This saves <em>polling</em> the USB interface as it reacts immediately, but only when needed.
----

=== Chaining ISRs ===
Sometimes one hardware interrupt may run several ISRs in turn.  There
are a couple of reasons this might be done:

*Insufficient hardware signals, so some have to share.
*Multiple services may be required by a single event.<br /> Example: a single timer tick may occur at regular intervals and be shared by multiple functions (rather than having dedicated hardware for each).

In these cases the dispatcher might run down a <em>list</em> of ISRs so each can check if it is needed.  Items may be added to or deleted from the list dynamically: consider, for example, peripherals using [[Extra:USB|USB]]…
----
{{BookChapter|1.2.1|8-11}}
{{PageGraph}}
{{Category|Exceptions}}
{{Category|IO}}