Important:
This is retired content. This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
A version of this page is also available for
4/8/2010

Interrupt latency variation is due to many unpredictable factors, such as what data is currently in the processor cache and how many other threads of various priorities exist. On some hardware, factors such as microprocessor speed, bus speed, and the speed of the manufacturer's interrupt vectoring routines determine the lower limits of interrupt latency.

Because high-priority threads can preempt the ISTs of device drivers, there is no absolute upper limit. In general, the latency for servicing interrupts is less than the latency for Microsoft Windows-based desktop platforms. Device drivers are unlikely to lose data unless they are starved for processor time by other high-priority threads running on the OS.

Nested interrupts and a high number of priority levels provide the tools to address these concerns when used appropriately. ISRs and ISTs that must run at high priority can now do so, and can preempt the processing of other, lower-level ISRs and ISTs. However, because nested interrupts only occur for interrupts of a higher priority than the currently executing ISR, you must assign the priority levels for your device drivers.

For information about technical articles and case studies on Windows Mobile real-time capabilities, see this Microsoft Web site .

See Also