windows核心原理分析之DPC函式的執行（1）

當發生中斷時，有些操作本來應該在中斷服務程式中完成，但是實際上卻是在退出中斷服務程式之後在乙個dpc函式中完成的。dpc是」deferred procedure call」的縮寫，意為推遲了的過程（函式）呼叫。這是因為，邏輯上應該放在中斷服務程式中完成的操作並非都是那麼緊迫，其中有一部分可能相對而言不那麼緊迫，而又比較費時間，實際上可以放在開中斷的條件下執行。如果把這些操作都放在中斷服務程式中，就會使關閉中斷的時間太長而引起中斷請求的丟失，因為整個中斷服務程式通常都是在關中斷的條件下執行的。為此，把中斷服務程式中不那麼緊迫卻比較費時，而又不必在關中斷條件下執行的操作分割出來，放在另乙個函式中，在開中斷的條件下加以執行，就可以縮短關中斷的時間。這樣的函式就是dpc函式。一般而言，中斷服務前期的操作是比較緊迫的，並且是必須關中斷的，此時可以很快地對外部裝置進行操作。此後，剩下的那部分操作便可以稍後在開中斷的條件下執行。所以有人曾經把這部分操作稱為中斷服務的」後半（bottom half）」，也有人把這兩半分別稱為」硬中斷」和」軟中斷」。之所以要把中斷服務分成前後兩半，是因為一次中斷服務的後半不如另一次中斷的前半那麼緊迫。

為此，核心中要有個dpc請求佇列，中斷服務程式執行完它的」前半」之後就把乙個dpc請求掛入這個佇列，要求核心呼叫相應的dpc函式，然後（形式上）就從中斷返回了。接著，如果沒有別的中斷請求，核心就會掃瞄這個dpc請求佇列，依次在開中斷的條件下執行這些dpc函式，直至又發生中斷或執行完佇列中的所有dpc函式。至於當前執行緒所要執行的程式，則只有在dpc請求隊列為空的時候才會繼續得到執行。顯然，這裡所體現的是」急事急辦」的原則，中斷是最急的，dpc函式其次，最後才是當前執行緒。windows核心的irql（即執行級別）就反映了這些活動的輕重緩急，dpc函式是在dispatch_level級別上執行的。

與dpc函式的執行有關的另乙個問題是堆疊的使用。我們知道，中斷服務程式所使用的堆疊就是當前執行緒的系統空間堆疊。中斷服務程式一般都是比較輕小的，占用一下當前執行緒的堆疊不至於會有問題；但是dpc函式就不同了，dpc函式有可能是比較大的，如果仍舊占用當前執行緒的堆疊，在最壞的情況下有可能造成堆疊溢位，所以最好是為dpc函式的執行另外配備乙個堆疊。

windows核心把dpc請求佇列放在每個cpu的prcb資料結構中。此外，prcb結構中還有一些別的與dpc有關的字段：

typedef struct _kprcb  
kprcb, *pkprcb;

其中的dpcdata[2]是大小為2的_kdpc_data結構陣列，其結構定義如下：

typedef struct _kdpc_data  
kdpc_data, *pkdpc_data;

可見，每個_kdpc_data結構中都有個佇列頭，這就是用於dpc請求佇列的。

dpcdata的大小為2，說明有兩個dpc請求佇列，它們是：

#define dpc_normal 0

#define dpc_threaded 1

顯然，其中之一是」常規」的dpc請求佇列，另乙個是」執行緒化」的dpc請求佇列。目前reactos已經實現的是常規dpc請求。

裝置物件的資料結構device_object中有個成分dpc，這是個kdpc資料結構，用來設定有關本裝置物件的dpc函式的資訊：

typedef struct _kdpc  
kdpc, *pkdpc, *restricted_pointer prkdpc;

裝置物件在初始化時通過keinitializedpc()設定好它的kdpc資料結構。

void ntapi  
keinitializethreadeddpc(in pkdpc dpc, in 
pkdeferred_routine deferredroutine,  
in pvoid deferredcontext)  
void ntapi  
kiinitializedpc(in pkdpc dpc, in pkdeferred_routine deferredroutine,  
in pvoid deferredcontext, in kobjects type)

windows核心原理分析之DPC函式的執行（1）

Windows核心原理與實現之核心載入

windows核心原理與實現

Windows核心原理與實現之驅動物件和裝置物件

windows核心原理分析之DPC函式的執行（1）

Windows核心原理與實現之核心載入

windows核心原理與實現

Windows核心原理與實現之驅動物件和裝置物件

相關推薦