school_archives/OSU Coursework/CS 444 - Operating Systems II/Writing Assignments/Final Paper/writing/interrupts.tex

\section{Interrupts}
\subsection{Overview}
Interrupts are a useful hardware feature of processors that are often overlooked by computer scientists and software developers. Interrupts do exactly what the name implies and interrupts whatever the processor is doing to instead do something else. Many kinds of interrupts exists such as timers that cause an interrupt after a certain period of time has elapsed, flag based interrupts that cause the processor to do something else if execution fails, or external hardware interrupts such as from a PS2 port that tells the processor it needs to stop to process some input from a device like a keyboard or mouse. Without interrupts, much of what makes a modern computer as powerful and versatile would not be possible as it would require a massive singular sequential polling loop to process every potential operation on the computer. It's not hard to imagine how difficult generating a screen full of graphics if the processor could be processing a math operation for seconds at a time, and all the while, graphical updates would stop. These interrupts are used on any modern processor from every major manufacturer 

\subsection{Individual OS Implementations and Features}
\subsubsection{Linux and FreeBSD}
For both of these operating systems, the underlying implementation is the same as they're both Unix based and the core design was built off the same foundation. The system sets up interrupt service routines (ISRs) as handlers for an interrupt occurring. Every individual interrupt has its own unique service routine that is connected to a c function in the driver for the piece of hardware. When the interrupt actually triggers, there are two portions to consider that they call the top half and bottom half. The top half is what is run during the duration of the hardware interrupt. This part must be kept as short as possible so that it doesn't break the timing of other aspects of the system. This section could do something as simple as setting a flag, queuing data, or moving a chunk of data from the hardware to ram. The lower section is used if the top half doesn't have enough time to process whatever needs to happen in the interrupt. This also is only used when the interrupt isn't highly timing specific. This work that has to be performed will be scheduled whenever there is free time, but is allowed to be interrupted by other top half interrupts if one occurs during its run. Internally, these Unix kernels set up some hardware timers on the CPU that run on a regular and fast basis to trigger frequent interrupts. These are used to perform tasks such as context switching of processes, or handling higher level software interrupts for hardware of software created interrupts that don't need true hardware interruption

\subsubsection{Windows}
In Windows, interrupts are handled by what they call trap handlers with the traps being their name for when the CPU "captures" the running thread so it can transfer execution to the handler. The trap handlers in turn trigger and interrupt service routine (ISR) that handles the low level processing of whatever has triggered it. In most cases, the interrupt is caused by hardware, such as a PCI express device telling the processor that it has data that it needs to send to it. The trap handler in this case would be handed off to an ISR in the driver for the particular piece of hardware. Software interrupts on the other hand could be used to signal to a higher level application that a time as passed, or some other useful even has occurred, but not necessarily triggered by hardware. To determine which interrupt should run, it is looked up in the interrupt dispatch table (IDT) and then hands off to the driver's ISR. Windows interrupt handlers also have what are called deferred procedure calls (DPCs), that are a way to process an interrupt where the processing does not have to be real-time. The interrupt creates a DPC that is scheduled whenever there is free time on the processor. This allows the kernel to keep the ISR short for tasks that don't require precision timing, but still generate an interrupt to let the system know something is ready to process.

\subsection{Comparisons}
\subsubsection{Windows vs. Linux/FreeBSD}
In this particular part of the operating system, the way that the Unix based and Windows kernels handle interrupts is actually pretty much the same. It's not hard to see the reason for this being that it's based more around how the hardware has to function than some arbitrary software decision made at a high level. Computers have strict timing requirements when it comes to interacting with hardware, and not obeying those requirements will lead to the OS crashing at best. In extreme circumstances, it could even cause hardware failure. In fact, I would not be surprised if the developers of the interrupt kernel systems were basing in on and Intel design document describing the best ways to implement the lowest level portion of the OS to be most efficient and be least likely to cause issues. It also makes sense when you consider that in older days of computing, interrupts were the only made to get seemingly concurrent things to happen, but the end user actually had access to these hardware systems directly. As computers got more and more complex, a framework was needed to keep all but driver developers from accidentally interacting with hardware systems they shouldn't be.