Interrupts: Difference between revisions
pc>Yuron No edit summary |
 Yuron [   PHRhYmxlIGNsYXNzPSJ0d3BvcHVwIj48dHI+PHRkIGNsYXNzPSJ0d3BvcHVwLWVudHJ5dGl0bGUiPkdyb3Vwczo8L3RkPjx0ZD51c2VyPGJyIC8+YnVyZWF1Y3JhdDxiciAvPmludGVyZmFjZS1hZG1pbjxiciAvPnN5c29wPGJyIC8+PC90ZD48L3RyPjwvdGFibGU+] (talk | contribs) m (1 revision imported) |
(No difference)
| |
Revision as of 12:46, 26 July 2019
| On path: OS Topics | 1: Concepts • 2: Cache • 3: Context • 4: Processor Privilege • 5: Process Scheduling • 6: Exceptions • 7: Interrupts • 8: Direct Memory Access (DMA) • 9: Virtualisation • 10: Hypervisor |
|---|
| On path: Exceptions | 1: Exceptions • 2: Reset • 3: System Calls • 4: Software Exceptions • 5: Emulator traps • 6: Memory Fault • 7: Interrupts • 8: Unix Signals |
|---|
| Depends on | Exceptions • Using Peripherals |
|---|
Interrupts – along with system calls, memory faults etc. – are a form of hardware-level exception. They are usually handled in a very similar way, calling a particular, privileged function then returning.
Unlike (e.g.) system calls, which are explicitly triggered by the running process, interrupts are triggered by hardware parts of the computer. They can be viewed as the hardware calling for software support.
Example: to keep time, the hardware will have a clock circuit which is counting ‘ticks’; this is quite simple to do in hardware even if the ticks are quite fast. It would be a waste of the processor’s resources to do this in software – plus it would need the software’s undivided attention so nothing else would get done! Every so often – say once per second – the clock on the user’s screen needs updating. This is too difficult for the hardware but it can call a software process (known as an Interrupt Service Routine (ISR)) to do the job.
The interrupt literally “interrupts” the executing process, taking control of the processor, executing a function (a.k.a. an interrupt service routine (ISR)) and returning. This can happen at any time; of course it is vitally important that this does not break the executing process by altering anything in its context.
There is a software analogy to the hardware interrupt process in some Unix signals and you can generate your own model here.
Unlike a process or thread context switch, servicing an interrupt merely ‘borrows’ a processor’s ‘attention’. Some data has to be saved and restored but this is not the process’ whole context, memory etc; (in most cases) the interrupted process is quickly resumed. This makes the interrupt process reasonably cheap in terms of time (and energy).
Interrupt services are normally kept quick and ‘lightweight’. However it is worth noting that the services requested are often urgent and keeping the interrupt latency low is important, especially in real-time systems.
The interrupt latency is the time between the hardware requesting the service and the effect taking place. For example, if the interrupt is caused by a key being pressed then the latency is the time from that character reaching the computer’s input peripheral device and the software removing it again. If the latency is too high, the input might be overrun; although this is unlikely with a keyboard, other devices can supply inputs at much greater rates.
Note that, in most cases, the interrupt service routine will not process input, simply moving it into an input queue to give more freedom for the applications software scheduling.
- Normal execution is confined to the code flow as written (here reduced to a simple loop).
Interrupts are enabled whilst the dot is green and disabled when it is red. - An enabled interrupt (click, almost anywhere) causes the execution to suspend (empty circle) and the ISR to run instead.
If interrupts are disabled, the interrupt will be pending until they are re-enabled. (This includes during execution of the ISR.) - When the ISR is complete, normal execution is resumed from the point it was suspended.
Any jerkiness in the ‘execution’ flow is caused by the underlying computer process-switching; it is not a deliberate part of the demonstration!
We also gave you a button to make it stop!
There are plenty of short video lectures ‘out there’: this one (8 mins.) for example is quite clear.
Interrupt service code
An interrupt is a ‘trap’ and raises the privilege level of the processor. The ISR is therefore part of the operating system kernel. In most cases both the code for the Interrupt Service Routine (ISR) and any associated data will be kept memory resident, not paged out (onto disk). This is important to keep the interrupt latency low.
Most interrupts deal with IO devices, which require some ‘careful’ handling; for example, sometimes devices can be read sensitive – i.e. they can change state when they are read from as well as when they are written to. It is therefore important that ISRs are executed, completely, once per interrupt request. The code will not be re-entrant. For the same reason, each hardware interrupt request will be directed to a single processor core in a multi-core system.
Interrupt enables
Typically, all interrupt sources have a separate ‘enable’ control, to switch them on and off. Unused interrupts are disabled and the connected hardware cannot interrupt the processor. In some instances, particular interrupts may only be enabled under certain circumstances, so enables may be controlled dynamically: this is a privileged function: users must not tinker. These signals may be implemented within the [peripheral devices)(Peripherals) or in a centralised interrupt controller (or, sometimes both).
In addition, there will be a global interrupt priority, controlled by the processor. This simplest case is a simple enable/disable (“all or nothing”) function; more sophisticated devices may implement some priority levels. This is important at reset time (for example) where the hardware is uninitialised and thus liable to produce ‘random’ inputs until dealt with by the boot process.
Interrupt priority
Sometimes interrupts are assigned priority levels. Their purpose is to allow one interrupt to pre-empt another ISR (i.e. one which is less urgent, and therefore of lower priority. When an ISR is begun, the priority is set so that the hardware only enables interrupts of a higher priority. This means that ISRs can be nested in the same way as function calls.
However, the ISRs are not re-entrant and recursion is forbidden. (This is implicit if you note the word “higher” above.)
This usually is only important if an ISR is very time consuming (a Bad Idea) or in time-critical Real Time systems.
Often, interrupts are also prioritised, with low priority being given to ‘slow’ devices (e.g. keyboard) and high priority to those requiring faster response (e.g. web-cam). High priority interrupts may be able to interrupt low-priority ISRs, in a similar way to the ‘nesting’ of procedures/methods.
Some example interrupts
Timer
A timer is a relatively simple hardware device – basically a counter which is triggered by a clock at a known frequency. It therefore measures the passage of time. This is probably in an inconvenient form: for example a 32-bit timer which counts every 10 us will repeat its sequence more than twice a day. It is therefore expedient to interrupt a processor at intervals and maintain the time in a longer variable. (A 64-bit variable would give nearly 6 million years.)
A regular timer interrupt may typically do little more than increment a variable, although it may also compare the current time with that of any sleeping processes (for example) and unblock any which are due to wake up.
In a time-sliced system, a timer interrupt may also allow the operating system to check how long a process has been running and may call the scheduler to swap processes. In this case the interrupted process will still be resumed at the interrupted point … eventually!
Time-slicing may use a different hardware timer from the elapsed-time clock. Keeping accurate time is often important; context switching can be a lot less precise. If interrupt priorities are being observed it is convenient to time-slice at low priority to avoid attempting this during other ISRs … which adds much complication, unnecessarily.
Character input
A simple I/O example is a serial line or similar: this can be envisaged as a keyboard example. An interrupt indicates that a character has arrived; the ISR will normally move this to a queue, maybe unblocking a blocked process if appropriate.
Character output
Sending characters with interrupts is a bit more complicated than receiving. First, imagine a system call has put some characters in a queue and one is in the process of being sent. The appropriate interrupt then indicates that the peripheral hardware is empty: – ready to send the next character. The ISR can then fetch that from the buffer.
The added complications come when the buffer:
- becomes empty – in which instance the response to the interrupt is to disable itself and return as there is no longer any need for it.
- stops being empty – the signal from the
put()call takes the form of enabling the interrupt again – probably eliciting an interrupt response as soon as the insertion system call allows it.
Disk block read
In most modern systems it is likely that the block transfer is facilitated by DMA. In this case the DMA controller only needs to interrupt to tell the processor the desired block is now complete in memory. The ISR then needs to decide if another block is wanted ((historically) typical size of disk block: 512 bytes; typical size of memory page: 4 KiB) or not and set up another transfer, unblock a process etc. appropriately.
USB device insertion/removal
These IO devices are clearly non-permanent. The [USB USB] interface device itself will signal changes in state.
Power failure
Quick – save important data to non-volatile store!
This is normally a high-priority interrupt since there may only be a short time left before the computer shuts down.
