Exceptions
On path: Exceptions | 1: Exceptions • 2: Reset • 3: System Calls • 4: Software Exceptions • 5: Emulator traps • 6: Memory Fault • 7: Interrupts • 8: Unix Signals |
---|
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 |
---|
Depends on | Concepts |
---|
In general, in computing terms, “exceptions” are circumstances which are outside the normal operations flow. For example, when accessing an array an exception could be caused if the index referred to an element beyond the size of that array.
You may already be familiar with some classes of exceptions, e.g. from Java.
The operating system software layer is also capable of generating
exceptions. You are probably already familiar with the ^C
method of
terminating an application; note that there will usually not be an
explicit check for this input in the application’s code.
There is a further exploration of this principle in the exercise on
exceptions.
Here we are primarily concerned with exceptions which originate from hardware which are normally handled by the operating system. The sort of exceptions supported by particular hardware varies but here are some examples of exceptions at the hardware level.
- Reset – used to start a system in a well defined way
- System call
- Emulator trap
- Memory fault
- Interrupt
- Privilege violation
- Arithmetic error (e.g. division by zero, numeric overflow)
- Debug breakpoint
- …
Here is a (somewhat cryptic) list of x86 processor exceptions.
It is likely that all of the exceptions supported by a particular machine call into the operating system. For space reasons we only describe a selected, illustrative subset here; see the individual articles for more details.
Common features
The typical hardware exception is a high-priority event which is likely to take precedence over other tasks. Some are a result of a software action (e.g. a system call); some originate purely from hardware (e.g. an interrupt); some come from an interaction between hardware and software (e.g. a page fault). All have a certain commonality in response.
An exception acts as a ‘call’ to the processor, invoking a method/procedure/subroutine/whatever-you-call-it. The process of the call also raises the privilege level of the processor so that it can legitimately interact with the hardware. This routine is entered at a well-defined address which is normally reserved for operating systems’ code and should have appropriate protection which stops user processes abusing the facility.
Now running trusted code, the processor can determine more information about the cause of the exception. It takes appropriate remedial action. Depending on the particular circumstances it may be able to deal with the exception transparently, and return to the user code transparently, or it may decide that the issue cannot be ‘fixed’ and not return, instead, perhaps, scheduling some other action.
The detailed behaviour may need to be a software (O.S.) decision. For example:
- A memory fault caused by a ‘rogue’ pointer probably indicates a process has crashed (or is trying to do something illicit) and the guilty process will be exterminated.
(E.g. “Segmentation fault”). - A memory fault caused by a virtual memory page fault will normally cause some corrective action and the user process will be resumed sometime later.
(Other processes may be scheduled in between.) - A memory fault used to track whether a page is still in use will simply note the status and return ‘immediately’.
(Some systems do do this – but don’t worry if you don’t follow this last point.)
The exception handler might also send a signal to communicate information back to a user process. A user process can sometimes register its own signal handlers for some exceptions.
There is an exercise for you to try this.
Exact and Inexact Exceptions
Hardware exceptions may be broadly classed as being ‘exact’ or ‘inexact’, depending on the relationship of the cause to the place the software responds to them.
- Exact exceptions occur at a fixed position. The most obvious example is the system call which is an explicit instruction at a fixed place in the code. A less obvious example is the memory fault; however in a system using virtual memory it is important that the exception handler can identify exactly where the ‘fault’ occurred (e.g. within a sequence of
load
operations) so that it can identify the correct page … and return to rerun the operation. - Inexact exceptions are typified by interrupts and there is no way to predict when they might be serviced. The implication for operating system code is never to allow interrupts in an atomic sequence of instructions to prevent context switching etc. within the sequence.