KeReleaseDispatcherDatabaseLock(OldIrql);
    } else {
        /* Return Locked and with a Wait */
        KTHREAD *Thread = KeGetCurrentThread();
        Thread->WaitNext = TRUE;
        Thread->WaitIrql = OldIrql;
    }
    /* Return the previous State */
    return PreviousState;
}[/code]
    參數(shù)Increment和Wait所起的作用與前面KeReleaseSemaphore()中的相同。所謂“設(shè)置事件”其實(shí)就是一種特殊的、變通的V操作。具體的操作分兩種情況：
    1. 如果IsListEmpty()為真，即等待隊(duì)列是空的、沒(méi)有線程在睡眠等待，就把Event->Header.SignalState設(shè)置成1。這樣，如果此后有線程對(duì)此事件對(duì)象執(zhí)行P操作、即NtWaitForSingleObject()，就因此而不必睡眠等待。這對(duì)于通知型和同步型的事件對(duì)象都是一樣。
    2. 已經(jīng)有線程在這個(gè)對(duì)象上睡眠等待，那就要從中喚醒一個(gè)或所有線程。這時(shí)候的處理取決于事件對(duì)象的類(lèi)型以及等待的方式：
    l 對(duì)于通知型的事件對(duì)象，或者等待者的等待方式是WaitAll，而且此前SignalState為0，就將SignalState置1，并通過(guò)KiWaitTest()喚醒這個(gè)線程，以及等待隊(duì)列中所有符合條件的線程?？墒?，要是SignalState本來(lái)就已經(jīng)是1，則沒(méi)有任何影響。
    l 否則，對(duì)于同步型的事件對(duì)象，并且等待者的等待方式是WaitAny，就通過(guò)KiAbortWaitThread()喚醒等待隊(duì)列中的第一個(gè)線程。此時(shí)并不改變SignalState的值。因?yàn)榧热粏拘蚜艘粋€(gè)線程，就已經(jīng)把這籌碼消耗掉了。
    這里KiWaitTest()和KiAbortWaitThread()的區(qū)別在于：KiWaitTest()是在一個(gè)while循環(huán)中對(duì)等待隊(duì)列中的所有進(jìn)程執(zhí)行KiAbortWaitThread()，條件是SignalState大于0。對(duì)于信號(hào)量，由于每喚醒一個(gè)線程就使SignalState減1，這循環(huán)很快就停止了，一般是只喚醒一個(gè)線程。但是如前所述，通知型事件對(duì)象在喚醒一個(gè)線程的時(shí)候不改變SignalState的值。于是，這個(gè)while循環(huán)就會(huì)喚醒等待隊(duì)列中的所有進(jìn)程。不過(guò)這里也有例外，如果其中的某個(gè)線程是在多個(gè)“可等待對(duì)象”上等待，而且等待方式是WaitAll，那就還要看是否別的條件也滿(mǎn)足了，不然就只好把它跳過(guò)，這也是KiWaitTest()的代碼中按排好了的。

    前面講過(guò)，一旦將通知型事件對(duì)象的SignalState設(shè)置成1，它就一直保持為1，P操作不會(huì)改變它的值。即使再對(duì)其執(zhí)行一次KeSetEvent()，也不會(huì)改變它的值，因?yàn)楸緛?lái)就已經(jīng)是1了。為了使其變成0，以便再次使用這個(gè)事件對(duì)象，就需要對(duì)其執(zhí)行另一個(gè)系統(tǒng)調(diào)用NtResetEvent()。同樣，NtResetEvent()的主體是KeResetEvent()。

[code][NtSetEvent() > KeResetEvent()]

LONG  STDCALL
KeResetEvent(PKEVENT Event)
{
    KIRQL OldIrql;
    LONG PreviousState;
   
    DPRINT("KeResetEvent(Event %x)\n",Event);
   
    /* Lock the Dispatcher Database */
    OldIrql = KeAcquireDispatcherDatabaseLock();
   
    /* Save the Previous State */
    PreviousState = Event->Header.SignalState;
   
    /* Set it to zero */
    Event->Header.SignalState = 0;
   
    /* Release Dispatcher Database and return previous state */   
    KeReleaseDispatcherDatabaseLock(OldIrql);
    return PreviousState;
}[/code]
    解釋就沒(méi)有必要了。注意調(diào)用NtResetEvent()的不必就是NtSetEvent()的調(diào)用者，而可以是別的線程或內(nèi)核模塊。不過(guò)有些內(nèi)核模塊只能調(diào)用KeResetEvent()，而不是NtResetEvent()。
    Windows還有個(gè)系統(tǒng)調(diào)用NtPulseEvent()，這是把NtSetEvent()和NtResetEvent()組合在了一起，相當(dāng)于先NtSetEvent()、然后馬上就NtResetEvent()。這樣，其效果就是喚醒已經(jīng)在通知型事件對(duì)象上等待的所有線程，但是下不為例。而對(duì)于同步型事件對(duì)象則大致等同于NtSetEvent()。
    可見(jiàn)，雖然“事件”實(shí)質(zhì)上是“信號(hào)量”的一種特例和變種，但是在使用上卻有著明顯的差別。信號(hào)量的“正宗”的用途是構(gòu)筑臨界區(qū)。在這種應(yīng)用中，一個(gè)線程得以通過(guò)P操作進(jìn)入臨界區(qū)的原因可能是有另一個(gè)線程執(zhí)行了V操作，但是既然進(jìn)了臨界區(qū)就總有從臨界區(qū)退出而執(zhí)行V操作的時(shí)候。這樣，一個(gè)線程在P操作以后總是有個(gè)V操作。從總體上看，每個(gè)線程的P操作和V操作是平衡的、即數(shù)量相等的。但是“事件”則不同，“事件”并不是用來(lái)構(gòu)筑臨界區(qū)、而純粹是用于線程間同步的。在這里，等待事件發(fā)生的一方總是執(zhí)行P操作，而發(fā)出事件通知的一方則總是執(zhí)行V操作。在前面對(duì)于“信號(hào)量”的比喻中把P操作比作領(lǐng)取通行證，把V操作比作交還通行證。相比之下，對(duì)于“事件”則相當(dāng)于領(lǐng)取的通行證從來(lái)不交還，而另有供應(yīng)者在不時(shí)地提供新的通行證。而且，特別有意義的是，發(fā)出事件通知的一方還不必非得是一個(gè)線程，也可以是內(nèi)核中的某些子系統(tǒng)，例如設(shè)備驅(qū)動(dòng)，所以也可以用于線程與內(nèi)核之間的同步，特別是廣泛地應(yīng)用于設(shè)備驅(qū)動(dòng)。當(dāng)然，發(fā)出事件通知的一方更不必局限于某一個(gè)特定的線程，而是任何一個(gè)線程都可以。
    為了幫助讀者加深對(duì)事件機(jī)制的理解，下面是一個(gè)內(nèi)核線程DebugLogThreadMain的代碼：

[code]VOID STDCALL
DebugLogThreadMain(PVOID Context)
{
  KIRQL oldIrql;
  IO_STATUS_BLOCK Iosb;
  static CHAR Buffer[256];
  ULONG WLen;

  for (;;)
    {
      LARGE_INTEGER TimeOut;
      TimeOut.QuadPart = -5000000; /* Half a second. */
      KeWaitForSingleObject(&DebugLogEvent, 0, KernelMode, FALSE, &TimeOut);
      KeAcquireSpinLock(&DebugLogLock, &oldIrql);
      while (DebugLogCount > 0)
      {
        if (DebugLogStart > DebugLogEnd)
        {
            WLen = min(256, DEBUGLOG_SIZE - DebugLogStart);
            memcpy(Buffer, &DebugLog[DebugLogStart], WLen);
            Buffer[WLen + 1] = '\n';
            DebugLogStart =  (DebugLogStart + WLen) % DEBUGLOG_SIZE;
            DebugLogCount = DebugLogCount - WLen;
            KeReleaseSpinLock(&DebugLogLock, oldIrql);
            NtWriteFile(DebugLogFile, NULL, NULL, NULL, &Iosb, Buffer, WLen + 1,
                        NULL, NULL);
        }
        else
        {
            WLen = min(255, DebugLogEnd - DebugLogStart);
            memcpy(Buffer, &DebugLog[DebugLogStart], WLen);
            DebugLogStart =
                   (DebugLogStart + WLen) % DEBUGLOG_SIZE;
            DebugLogCount = DebugLogCount - WLen;
            KeReleaseSpinLock(&DebugLogLock, oldIrql);
            NtWriteFile(DebugLogFile, NULL, NULL, NULL, &Iosb, Buffer, WLen,
                        NULL, NULL);
          }
        KeAcquireSpinLock(&DebugLogLock, &oldIrql);
      }
      KeResetEvent(&DebugLogEvent);
      KeReleaseSpinLock(&DebugLogLock, oldIrql);
    }
}[/code]

    這個(gè)內(nèi)核線程是為內(nèi)核調(diào)試日志(Log)服務(wù)的。內(nèi)核中有個(gè)環(huán)形緩沖區(qū)DebugLog[]，以及用作該數(shù)組下標(biāo)的變量DebugLogStart和DebugLogEnd，還有表示環(huán)形緩沖區(qū)中數(shù)據(jù)長(zhǎng)度的變量DebugLogCount。不管是哪一個(gè)線程，只要是進(jìn)入了內(nèi)核，如果需要在日志中寫(xiě)上一筆，就可以把字符串拷貝到這個(gè)環(huán)形緩沖區(qū)中，然后要求這個(gè)內(nèi)核線程把內(nèi)容寫(xiě)到一個(gè)日志文件中。為此當(dāng)然需要同步，這是通過(guò)一個(gè)(同步型)事件對(duì)象DebugLogEvent達(dá)成的。由于是在內(nèi)核中，所以這里對(duì)事件對(duì)象的操作都直接調(diào)用其內(nèi)核版本，例如KeResetEvent()、而不是NtResetEvent()。此外，對(duì)于環(huán)形緩沖區(qū)的使用當(dāng)然還需要互鎖，這是通過(guò)“空轉(zhuǎn)鎖”DebugLogLock實(shí)現(xiàn)的，不過(guò)那不是我們此刻所關(guān)心的。
    每當(dāng)需要生成一項(xiàng)日志時(shí)，可以調(diào)用DebugLogWrite()：

[code]VOID
DebugLogWrite(PCH String)
{
  KIRQL oldIrql;

   . . . . . .
   KeAcquireSpinLock(&DebugLogLock, &oldIrql);

   if (DebugLogCount == DEBUGLOG_SIZE)
   {
      DebugLogOverflow++;
      KeReleaseSpinLock(&DebugLogLock, oldIrql);
      if (oldIrql < DISPATCH_LEVEL)
      {
        KeSetEvent(&DebugLogEvent, IO_NO_INCREMENT, FALSE);
      }
       return;
   }

   while ((*String) != 0)
   {
      DebugLog[DebugLogEnd] = *String;
      String++;
      DebugLogCount++;

      if (DebugLogCount == DEBUGLOG_SIZE)
      {   
        DebugLogOverflow++;
        KeReleaseSpinLock(&DebugLogLock, oldIrql);
        if (oldIrql < DISPATCH_LEVEL)
        {
           KeSetEvent(&DebugLogEvent, IO_NO_INCREMENT, FALSE);
        }
        return;
      }
      DebugLogEnd = (DebugLogEnd + 1) % DEBUGLOG_SIZE;
   }

    KeReleaseSpinLock(&DebugLogLock, oldIrql);

    if (oldIrql < DISPATCH_LEVEL)
    {
      KeSetEvent(&DebugLogEvent, IO_NO_INCREMENT, FALSE);
    }
}[/code]

    對(duì)于這段代碼，以及對(duì)于DebugLogWrite()和DebugLogThreadMain()之間怎樣互動(dòng)，這里就不作解釋了。只是要指出：DebugLogWrite()的每次執(zhí)行可能都在不同線程的上下文里、代表著不同的線程，因?yàn)槿魏尉€程都可以調(diào)用DebugLogWrite()。另外，想必讀者已經(jīng)注意到，KeResetEvent()是由DebugLogThreadMain()自己調(diào)用、而不是由別的線程調(diào)用的。

    介紹完事件對(duì)象，還應(yīng)該提一下，Windows還有一種特殊的“事件對(duì)(EventPair)”對(duì)象。與此有關(guān)的系統(tǒng)調(diào)用有這么一些：
[code]   NtCreateEventPair()
    NtOpenEventPair()
    NtWaitHighEventPair()
    NtWaitLowEventPair()
    NtSetHighWaitLowEventPair()
    NtSetLowWaitHighEventPair()
    NtSetHighEventPair()
    NtSetLowEventPair()[/code]

    顧名思義，“事件對(duì)”就是把兩個(gè)事件對(duì)象緊密地組合在一起。事實(shí)上也正是如此，一個(gè)事件對(duì)由“高”、“低”兩個(gè)事件對(duì)象組合構(gòu)成，其設(shè)計(jì)意圖是用于“點(diǎn)對(duì)點(diǎn)”的雙向進(jìn)程間通信。實(shí)際上這是為提高Windows進(jìn)程與服務(wù)進(jìn)程Csrss之間的通信效率而設(shè)置的(Csrss是Windows子系統(tǒng)的管理/服務(wù)進(jìn)程)。早期的csrss承擔(dān)著許多操作，Windows進(jìn)程與Csrss之間的通信非常頻繁，所以其效率至關(guān)重要。這種進(jìn)程間通信的典型情景就是一方喚醒另一方、自身卻又進(jìn)入睡眠，反過(guò)來(lái)等待被對(duì)方喚醒，就像打乒乓球一樣，為此就專(zhuān)門(mén)設(shè)計(jì)了NtSetHighWaitLowEventPair()和NtSetLowWaitHighEventPair()兩個(gè)系統(tǒng)調(diào)用。不僅如此，為了盡可能地提高效率(在這種情況下的優(yōu)化甚至是以CPU的時(shí)鐘周期數(shù)計(jì)算的)，還專(zhuān)門(mén)單獨(dú)分配了兩個(gè)中斷向量0x2B和0x2C，而不跟別的系統(tǒng)調(diào)用合用0x2E。不過(guò)，后來(lái)Csrss的許多操作被移到了內(nèi)核中，不再需要那么頻繁的進(jìn)程間通信了，因而在效率上的容忍度也寬松了一些，所以現(xiàn)在又回到了0x2E，而不再使用0x2B和0x2C這兩個(gè)中斷向量。

5． 命名管道(Named Pipe)和信箱(Mail Slot)
    前面提到，如果從字面上理解，那么進(jìn)程間通信也可以通過(guò)磁盤(pán)文件而實(shí)現(xiàn)。但是，把信息寫(xiě)入某個(gè)磁盤(pán)文件，再由另一個(gè)進(jìn)程從磁盤(pán)文件讀出，在速度上是很慢的。固然，由于文件緩沖區(qū)(Cache)的存在，對(duì)磁盤(pán)文件的寫(xiě)和讀未必都經(jīng)過(guò)磁盤(pán)，但是那并沒(méi)有保證。再說(shuō)，普通的文件操作也沒(méi)有提供進(jìn)程間同步的手段。所以通過(guò)普通的磁盤(pán)文件實(shí)現(xiàn)進(jìn)程間通信是不太現(xiàn)實(shí)的。但是這也提示我們，如果能實(shí)現(xiàn)一種特殊文件，使得對(duì)文件的讀寫(xiě)只在緩沖區(qū)中進(jìn)行(而不寫(xiě)入磁盤(pán))，并且實(shí)現(xiàn)進(jìn)程間的同步，那倒是個(gè)不壞的主意。命名管道就是這樣一種特殊文件。實(shí)際上，命名管道還不僅是這樣的特殊文件，它還是一種網(wǎng)絡(luò)通信的機(jī)制，只是當(dāng)通信的雙方存在于同一臺(tái)機(jī)器上時(shí)，才落入本文所說(shuō)的進(jìn)程間通信的范疇。
    既然命名管道是一種特殊文件，它的創(chuàng)建、打開(kāi)、讀寫(xiě)等等操作就基本上都可以利用文件系統(tǒng)中的有關(guān)資源加以實(shí)現(xiàn)。當(dāng)然，這畢竟是一種特殊文件，對(duì)于使用者來(lái)說(shuō)，最大的特殊之處在于這是一個(gè)“先進(jìn)先出”的字節(jié)流，不能對(duì)其執(zhí)行l(wèi)seek()一類(lèi)的操作。
    先看命名管道的創(chuàng)建，Windows的Win32 API上提供了一對(duì)庫(kù)函數(shù)CreateNamedPipeA()和CreateNamedPipeW()，前者用于ASCII碼字符串，后者用于“寬字符”即Unicode的字符串，實(shí)際上前者只是把8位字符轉(zhuǎn)換成Unicode以后再調(diào)用后者。對(duì)CreateNamedPipeW()的調(diào)用大致如下：

[code]  Handle = CreateNamedPipeW(L"[A]\\\\.\\pipe\\MyCont