IRQL深入解析(1)--IRQL级别

       IRQL = Interrupt Request Level.即中断执行的优先级。一个由windows虚拟出来的概念，划分在windows下中断的优先级，这里中断包括了硬中断和软中断，硬中断是由硬件产生，而软中断则是完全虚拟出来的。
        IRQL = Interrupt Request.中断请求，当中断发生后，发生中断的设备通过它使用的中断请求信号线象中断控制器报告中断。CPU可以通过IRQ号来识别中断。

        如果某个Interrupt产生了，且IRQL <= 目前Processor的IRQL Setting，那么将不会影响目前程序的运行。如果IRQL > 目前Processor的IRQL Setting，将执行中断程序，总而言之，较搞优先级的Interrupt中断较低优先级的Interrupt。通过函数KeGetCurrentIRQL()可以得到目前Processor的IRQL。可用的IRQL如下：

软件IRQL(Software IRQL )
PASSIVE_LEVEL 0 // Passive release level
LOW_LEVEL 0 // Lowest interrupt level
APC_LEVEL 1 // APC interrupt level
DISPATCH_LEVEL 2 // Dispatch level
硬件IRQL(Hardware IRQL )
DIRQL: from 3 to 26 for device ISR
PROFILE_LEVEL 27, 0x1B // Timer used for profiling.
CLOCK1_LEVEL 28, 0x1C // Interval clock 1 level - not used on x86
CLOCK2_LEVEL 28, 0x1C // Interval clock 2 level
SYNCH_LEVEL 28, 0x1C // Synchronization level
IPI_LEVEL 29, 0x1D // Interprocessor interrupt level
POWER_LEVEL 30, 0x1E // Power failure level
HIGH_LEVEL 31, 0x1F // Highest interrupt level
数值越大代表其IRQL的优先级越高。在驱动开发中，常见的由以下三个

      PASSIVE_LEVEL

      DISPATCH_LEVEL,

      DIRQL
使用SpinLock的可解決在多個驅動程式中同步的問題。DDK提供了兩組function。

KeAcquireSpinLock()
KeReleaseSpinLock()
及

KeAcquireSpinLockAtDpcLevel()
KeReleaseSpinLockAtDpcLevel()
      根據DDK上所說，KeAcquireSpinLock()僅能在IRQL < = DISPATCH_LEVEL的狀況下執行。不過，如果想DISPATCH_LEVEL來執行，最好還是用 KeAcquireSpinLickAtDpcLevel(). DDK上也說了，不要太過份依賴SpinLock作為資料同步的機制。原因在於KeAcquireSpinLock()一旦被呼叫，將會導致目前的 IRQL LEVEL提升至DISPATCH_LEVEL。此時，Windows Dispatcher的scheduler將會無法被執行。導致系統正常的response變慢。因此，在IRQL已經位於DISPATCH_LEVEL 時，就應該呼叫KeAcquireSpinLockAtDpcLevel()。實際上，KeAcquireSpinLockAtDpcLevel()什麼 也沒有作。因為，在DISPATCH_LEVEL時，所有routine的執行已經是同步了。所以沒有進一步進行SpinLock()的必要了。 如果是在IRQL < DISPATCH_LEVEL的狀況下呢？這個時候去呼叫KeAcquireSpinLock()，將會導致企圖將IRQL降低到DISPATCH_LEVEL的狀況發生。 而routine自行降低IRQL是不可以的。