DESIGN PROCESS OF REAL-TIME OPERATING SYSTEMS (RTOS) - Software Design for Six-Sigma: A Roadmap for Excellence - page 62

line. The pulse needs to be long enough for the system to recognize it; otherwise,
the interrupt may be overlooked by the system and it will not get serviced. Level-
triggered interrupts are requested by the device setting the line to either high or low,
whichever one will indicate an interrupt on the system. The level-triggered interrupt
method is often preferred over the edge-triggered method because it holds the line
active until serviced by the CPU. 1 Even though line sharing is allowed with level-
triggered interrupts, it is not recommended for real-time operating system design
because this leads to nondeterministic behavior. A concern regarding the hardware-
triggered interrupt is interrupt overload. Hardware interrupts that are triggered by
external events, such as user intervention, can cause unexpected load on the system
and put task deadlines at risk. The design of the operating system can include special
scheduling algorithms that can address an unexpected increase in hardware interrupts.
One such method suggested ignoring some interrupts when experiencing a higher
than normal arrival rate. It was argued that it is better to risk slight degradation
in performance than risking overloading the whole system, especially in the case
where the interrupt frequency is drastically higher than what was estimated (Regehr
& Duongsaa, 2005).
A software interrupt is one that has an instruction associated with it, and it is
executed by the CPU. The instruction may be for a system call or caused by a trap. A
process or task may cause a software interrupt so that the CPU will go into supervisor
mode so that I will execute and access protected memory. A trap occurs when an
unexpected or unintended event happens that causes an error with the system. Some
examples are divide-by-zero errors or register overflow.
When an interrupt occurs, the control is transferred to the Interrupt Service Routine
or ISR. A context switch occurs when information specific to the current process, such
as registers and the program counter, are saved off to the stack and the new process
information is loaded. The latency of an ISR must be both minimized and determined
statistically for use with real-time operating systems. Interrupts are usually disabled
while the code inside of the ISR is being executed; this is another reason why the ISR
latency must be minimized so the system does not miss any interrupts while servicing
another interrupt.
Polling is another method an operating system may use to determine whether a
device needs servicing. Polling differs from interrupts in that instead of the device
notifying the system that it needs service, the service will keep checking on the device
to see whether it needs service. These “checks” are usually set up on regular time
intervals, and a clock interrupt may trigger the operating system to poll the device.
Polling is generally viewed as wasted effort because the device may not need to be
serviced as often as it is checked or it may be sitting for some time waiting to be
serviced before its time quantum is up and serviced. However, devices that are not
time critical may be polled in the idle loop, and this can make the system more efficient
because it cuts down on the time to perform the context switch. Hence, there may be
some benefits to having an RTOS that supports' polling in addition to interrupts. 2
1 http://en.wikipedia.org/wiki/Interrupt.
2 FreeBSD Manual Reference Pages - POLLING, February 2002.