Rise Of Multiprocessing/Multithreading Sharpens Focus On Interrupts

TWO INTERRUPT ARCHITECTURE APPROACHES
Table 1 provides a list of symbols used to represent the processing performed in each type of RTOS interrupt architecture. Table 2 depicts the functional components of the unified interrupt architecture in two different cases.

The total system overhead is greater in the RTOS with a segmented interrupt architecture. In both the non-preemption and preemption cases, the segmented interrupt architecture RTOS introduces an additional (1*CS, 1*CR, 2*S, and 1*CC) of overhead (Fig. 2). It appears the most wasteful overhead case is the non-preemptive case, since the unified interrupt RTOS simply returns to the point of interrupt if a higher-priority thread wasn't made ready by the ISR processing.

Another performance benefit of the unified RTOS approach is that only the interrupted thread's scratch registers need to be saved/restored in this case. This isn't possible with a segmented interrupt RTOS, since it doesn't know what the ISR2 portion of the ISR will do during the actual interrupt processing. Hence, segmented interrupt RTOSs must save the full thread context on every interrupt. In the non-preemptive case, the CS and CR performance is much slower in the segmented interrupt RTOS, although this additional overhead hasn't been factored into this comparison.

The segmented interrupt architecture is claimed to have an advantage with regard to its response to interrupts. The whole idea behind never disabling interrupts is to make interrupt response faster. However, while it sounds good, several practical problems crop up with this approach.

Although the segmented interrupt RTOS doesn't disable interrupts, the hardware itself does when processing other interrupts. Therefore, the worst-case L in the segmented interrupt RTOS is actually the time interrupts are locked out during the processing of another interrupt. Also, interrupts could be locked out frequently in an application if the segmented interrupt RTOS uses a trap or software interrupt to process RTOS service requests. In such cases, the hardware will lock out interrupts while processing the trap. Finally, the application itself might have interrupt lockout so that it can manipulate data structures shared among multiple threads. All of these issues make "L" a non-zero value and largely defeat the purpose of designing an RTOS with the claim of L approaching zero.

SPECIAL INTERRUPT CHALLENGES
Briefly locking out interrupts while an ISR or system service modifies crucial data structures inside the RTOS will reliably prevent any other program in a conventional application from jumping in and making uncoordinated changes to the critical area being used by the executing code.

This approach, though, isn't sufficient in a multithreaded or multiprocessing application, since there's the potential for a switch to a different TC. Or, a memory reference instruction may be executed by a different processor core that's not impeded by the interrupt lockout. As a result, it might operate on the critical area. A variety of methods can be used to disable multithreading/multiprocessing while the data structure is being modified.

Multithreading and multiprocessing meet the demands for consumer, networking, storage, and industrial device applications when it comes to high performance, with only minor increases in cost and power consumption. The multithreading and multiprocessing approaches have their own advantages and strengths, and there's no reason the two approaches can't be combined for "the best of both worlds."

With relatively simple exceptions, application code can run unchanged when moving from conventional to multithreaded or multiprocessor applications. Thanks to multithreading, it's easy and inexpensive to use the CPU cycles that are often wasted by conventional RISC processors or multiprocessing, and thus exploit the economies of scale via multiple cores.