When a device, such as a CD Burner is tasked with writing data to a disc, it would be a waste of both time and resources to stop all other programs from running until the CD Drive had completed it's task. As processors are incapable of doing nothing, it would instead constantly check whether the CD drive had yet completed it's task.
This is known as Polling. The CPU is busy performing the task, but is effectively doing nothing as all it is doing is checking whether the task to complete. In a multiprogramming environment this is extremely wasteful and instead of constantly checking (ie: 'waiting') the processor could instead perform it's other tasks while the slower CD drive is busy doing it's task (writing data to the disk).
This though brings another problem. If the processor does stop Polling the CD drive and starts another task, these new tasks may take longer than the CD drive's task and so would cause a delay between the CD drive completing it's task and the processor detecting the completion of the task. It would result in the process using the CD drive being blocked and having to wait for the processor to detect it has finished. Not until then could it could complete it's I/O operation.
The solution to these two problems is the use of Interrupts. Interrupts allow a device to pro-actively signal the processor as soon as it has completed it's I/O task. This both prevents the need for busy-waits (the constant checking) and reduces the post-task idle time. Interrupts are signalled by use of an Interrupt Request Flag which is part of the CPU and is checked by the Control Unit during each instructions fetch-execute cycle. When a device had completed it's task, it sets it's own flag to 'done', which via the use of XOR logic, sets the CPU's interrupt request flag.
Upon receiving an interrupt the processor will stop executing it's “current” sequence of instructions and branch to a new set (I say “current” as in reality the processor has completed one part of the instruction sequence and is in the process of retrieving the next part).
This new set of instructions requested by the interrupting device are held in a memory address and the processor will go there to retrieve it's new task and so allow completion of the device's I/O operation.
To do this, the processor will store the Program Counters location of the previous tasks next instruction – the one it would of executed had it not of received an interrupt.
When the CPU begins to execute this new task, it's registers will still contain the values from the previous interrupted instruction sequence. To prevent these being lost, the Interrupt Handler will first perform a Context Switch to save these values and in their place put it's own values for each CPU register so that it can return to the previous task and complete it's instruction sequence when finished.
The next step for the Interrupt Handling Mechanism is to determine which device caused the interrupt. The old method was simply to check all the devices done flags, but now a newer, faster approach is taken in the form of an Interrupt Vector aka Descriptor Table.
The Interrupt Vector uses an array of interrupt request flags. If for example the computer has x devices and the vector has y coordinates, then x/y device done flags are connected to each vector coordinate. Secondly there is a table which contains the entry point for y different Interrupt Handlers stored in memory. If coordinate z in the Interrupt Vector is set to TRUE, then the normal instruction sequence will be is interrupted and the zth Interrupt Handler from the table of Interrupt Handlers is started.
It comprises of 256 4-byte pointers. It has two modes; Real Mode and Protected Mode. In Real Mode the Interrupt Vector it is located within the first 1k of memory, when in Protected Mode it can be located anywhere within physical memory.
Another scenario which requires a solution is the possibility that interrupt(s) may occur while the Interrupt Handler is already processing another interrupt.
This scenario is called a Race Condition and an example of one would be if a second interrupt occurred whilst the Interrupt Handler was performing a Context Switch and determining the device which caused the interrupt. When this second interrupt occurs, it is difficult to ensure that the proper values will be saved by the Context Switch and so will the original interrupting device be correctly located. Any error in this process would cause one of the two instruction sequences to fail.
The solution to preventing race conditions is a mechanism which blocks interrupts from being detected by the processor, and therefore interrupting the Handler. This mechanism is a flag contained within the CPU, which when set to TRUE, the CPU does detect interrupts, when it is set to FALSE it cannot.
When the flag is set to TRUE and the CPU detects an interrupt, the processor sets the interrupt enable flag to FALSE, this prevents any further interrupts being detected, and so it is able to carry out the critical handling of the interrupt. Once completed, the processor sets the interrupt enable flag back to TRUE, once again allowing new interrupts to be detected and the I/O task is allowed to complete.
When the interrupt enable flag is set to FALSE, it is only the first interrupt to occur after the setting of the flag which will be saved. It is saved because the device's done flag will have been set to TRUE and will remain so until the Interrupt Handler executes. Any further interrupts will not be saved and therefore lost. It is completely up to other device(s) whose interrupts have been lost to keep issuing interrupts until they are either detected by the processor, or they issue the first interrupt after the processor has disabled interrupts allowing it's interrupt to be saved.
This is the book I would recommend for anyone wishing to gain an understanding of the basic fundamentals of operating systems.
The subjects contained within are explained much more clearly than the other books I have read on the same subject. Whilst it may not go into as much depth as other books, I found it was this book which provided me a good solid understanding in an easy to understand way.
Copyright 2009, BinarySoldier.net. All rights reserved. | Privacy Policy