No Interrupts, Please!

An application program written to run under a single-tasking OS typically is master of all it surveys. It can communicate with any IO device, any memory location, disable interrupt recognition if it doesn't want to be interrupted, etc. In a single task environment, the program can disable recognition of interrupts if it will not adversely affect its own operation (the only program executing in the system).

If this same program is run under the management of a multitasking OS, however, it can cause severe problems. If permitted to execute a CLI (Clear Interrupt Enable) instruction, the EFlags[IF] bit is cleared to zero and, as result, the processor will no longer recognize interrupt requests originated by IO devices throughout the system. This means that these devices may not receive the servicing they require on a timely basis. As a result, they may suffer from buffer overflow or underflow conditions. This can result in anything from poor performance of a subsystem to completely flawed operation (data may be lost due to insufficient temporary buffer space within the subsystem). It should be noted that an IO device may generate an interrupt request to signal an event to another program that is currently suspended. The correct action may be for the processor to recognize the request, perform a task switch to the other program, service the request, and return to the interrupted task.

To summarize, the processor and the OS should not permit the application (written for a single-task OS environment) to execute the CLI instruction. An attempt to execute CLI should cause the processor to trap out to the OS. The OS would then set a bit indicating that this task prefers not to be interrupted. The EFlags[IF] bit would not really be cleared, so the processor would still be able to recognize interrupt requests. The OS then resumes execution of the task. If an interrupt request is detected while this task is still executing, the processor jumps to a special routine to determine if this particular interrupt request is deemed important enough to interrupt the currently executing program. If not, the OS marks this request for subsequent servicing and resumes the interrupted task. The request is serviced after the current task has completed its time slice and has been suspended. If the request is considered important enough to be serviced immediately, the OS permits the processor to execute the IO device's interrupt service routine and then resumes the interrupted task.