“Windows不是实时操纵系统”，这句话重复在NTDEV论坛中被提到。当某小我私家测验考试为非Windows兼容的设备（好比一个期望软件在很短的时间片之内响应的设备）写一个插件的时候，凡是会遇到这个问题。
实时操纵系统的界说是，在满足最低要求的情况下，以可估量的方法执行。它必需严格确保在很短的时间片之内响应请求。凡是可以分为软实时和硬实时环境。对付软实时，最重要的是快速响应，一次请求丢掉不会造成整体掉败。在硬实时环境中，作为比拟，不允许任何意料之外的延时，任何请求丢掉意味着整体掉败。凡是这样的环境都撑持实时任务。
在Windows里，所有对操纵系统的请求都基于最佳效果来措置惩罚惩罚，不保证响应时间。因此，Windwos能够在1秒钟时间内措置惩罚惩罚成千上万的请求，简单来说，它不能确保每个请求会在指定的时间片中被措置惩罚惩罚。
在大大都使用中，Windows是基于性能和吞吐量来设计和优化的，不是为了实时任务和低延迟，这凡是是有斗嘴的。针对大大都使用所存眷的平均吞吐性能的优化方案，和针对实时请求存眷的最大响应时间的解决方案对比，最糟糕的功效是请求丢掉。这意味着每一个独立的请求或操纵都很重要。
有很多实时请求相关的解决方案，范畴从产业、医疗、军工、航空、科研到高精度多媒体应用。举个简单的要求实时性的应用，“实时音频”，好比软件合成器，需要发声以响应MIDI键盘的按键，延时不能赶过几毫秒。音频流必需是持续的，任何单击、弹出和释放都可能中断音频流，影响音频功效。这意味着所有的请求都切合截止时间。
事实上，实时应用中的延时问题，好比“在发声之前按键”延时问题，本来就有，而不是计算机时代的产物。好比说，风琴手，必需预读并在好几秒钟后才华听到他们吹奏的声音，空气必需颠末庞大的机制在管道中流动，声音必需从教堂的角落回传到耳朵。
在使用声音合成器和音频插件时，实时音频应用中的延时问题，凡是有他们用户模式下的实现逻辑。就是说相较于运行在IRQL（Interrupt ReQuest Level中断请求）的设备驱动，他们越发有机会被中断（好比翻页、打算）。
最后，，注意本文的目的，我们忽略特定的Windows特性，如基于某些特定用途的IRQL PASSIVE_LEVEL中断措置惩罚惩罚和UMDF，凡是不是为实时措置惩罚惩罚而设计的。
低延时的仇敌
为了便于理解，为什么Windows不是合适的实时措置惩罚惩罚操纵系统，我们仔细看一其中断驱动设备的实现，它要在截止时间内在用户模式下措置惩罚惩罚请求。然后我们一边解释哪些问题会造成不受欢迎的延时。
对付一其中断驱动的实时性敏感的设备，Windows能够及时响应请求是很重要的。对付接下来将要讨论的实时措置惩罚惩罚的仇敌，延时可能在实时措置惩罚惩罚中被引入。逻辑上，在一次中断的措置惩罚惩罚期间，IRQL降的越低，从ISR到DPC再回到用户措置惩罚惩罚，越有可能引起永劫间和频繁的延时。
中断/ISR
设备指示需要引起软件注意的要领，是孕育产生一其中断。CPU收到设备发出中断信号后，将该中断注册为一个ISR（Interrput Service Routine）来措置惩罚惩罚。
ISR的执行可能被种因素推迟。CPU可能姑且推迟中断，操纵系统正在为一个高级的中断处事，姑且停用一些可屏蔽的中断，造成整个系统的锁定状态或者其他。同样的，中断可能被硬件因素推迟。遗憾的是，这类中断推迟不能单独通过软件来丈量。需要硬件的撑持，或者使用总线分析【在现代Intel架构系统中，我们知道硬件延时长短常小的，凡是小于1毫秒】。本文中，我们仅讨论中断措置惩罚惩罚中的软件延时，就是从ISR开始措置惩罚惩罚到中断被软件措置惩罚惩罚的期间。
因为Windows不允许控制设备中断的优先级，任何ISR执行的时候可以被更高级的中断抢占，除非通过提升IRQL来阻止此类抢占。ISR措置惩罚惩罚过程中的延时，也可能由其他因素引入，好比措置惩罚惩罚系统时钟、IPI（Inter Processor Interrupt）例程引起的操纵系统中断，或者不受操纵系统控制的因素，好比SMI（System Management Interrupt）例程，以及稍后会讨论的其他各类硬件因素。
DPC
如果该中断的处事需要永劫间运行，ISR通通例划一个DPC（Deferred Procedure Call）。DPC在一个较低的IRQL上措置惩罚惩罚I/O操纵，设备和系统中断可以抢占他的执行。如果中断的处事需要以用户模式进行，也需要一个DPC，受IRQL的强加在ISR的限制不允许恢复期待的东西或唤醒用户模式的线程。