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è)置事件”其實就是一種特殊的、變通的V操作。具體的操作分兩種情況：
    1. 如果IsListEmpty()為真，即等待隊列是空的、沒有線程在睡眠等待，就把Event->Header.SignalState設(shè)置成1。這樣，如果此后有線程對此事件對象執(zhí)行P操作、即NtWaitForSingleObject()，就因此而不必睡眠等待。這對于通知型和同步型的事件對象都是一樣。
    2. 已經(jīng)有線程在這個對象上睡眠等待，那就要從中喚醒一個或所有線程。這時候的處理取決于事件對象的類型以及等待的方式：
    l 對于通知型的事件對象，或者等待者的等待方式是WaitAll，而且此前SignalState為0，就將SignalState置1，并通過KiWaitTest()喚醒這個線程，以及等待隊列中所有符合條件的線程。可是，要是SignalState本來就已經(jīng)是1，則沒有任何影響。
    l 否則，對于同步型的事件對象，并且等待者的等待方式是WaitAny，就通過KiAbortWaitThread()喚醒等待隊列中的第一個線程。此時并不改變SignalState的值。因為既然喚醒了一個線程，就已經(jīng)把這籌碼消耗掉了。
    這里KiWaitTest()和KiAbortWaitThread()的區(qū)別在于：KiWaitTest()是在一個while循環(huán)中對等待隊列中的所有進程執(zhí)行KiAbortWaitThread()，條件是SignalState大于0。對于信號量，由于每喚醒一個線程就使SignalState減1，這循環(huán)很快就停止了，一般是只喚醒一個線程。但是如前所述，通知型事件對象在喚醒一個線程的時候不改變SignalState的值。于是，這個while循環(huán)就會喚醒等待隊列中的所有進程。不過這里也有例外，如果其中的某個線程是在多個“可等待對象”上等待，而且等待方式是WaitAll，那就還要看是否別的條件也滿足了，不然就只好把它跳過，這也是KiWaitTest()的代碼中按排好了的。

    前面講過，一旦將通知型事件對象的SignalState設(shè)置成1，它就一直保持為1，P操作不會改變它的值。即使再對其執(zhí)行一次KeSetEvent()，也不會改變它的值，因為本來就已經(jīng)是1了。為了使其變成0，以便再次使用這個事件對象，就需要對其執(zhí)行另一個系統(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]
    解釋就沒有必要了。注意調(diào)用NtResetEvent()的不必就是NtSetEvent()的調(diào)用者，而可以是別的線程或內(nèi)核模塊。不過有些內(nèi)核模塊只能調(diào)用KeResetEvent()，而不是NtResetEvent()。
    Windows還有個系統(tǒng)調(diào)用NtPulseEvent()，這是把NtSetEvent()和NtResetEvent()組合在了一起，相當(dāng)于先NtSetEvent()、然后馬上就NtResetEvent()。這樣，其效果就是喚醒已經(jīng)在通知型事件對象上等待的所有線程，但是下不為例。而對于同步型事件對象則大致等同于NtSetEvent()。
    可見，雖然“事件”實質(zhì)上是“信號量”的一種特例和變種，但是在使用上卻有著明顯的差別。信號量的“正宗”的用途是構(gòu)筑臨界區(qū)。在這種應(yīng)用中，一個線程得以通過P操作進入臨界區(qū)的原因可能是有另一個線程執(zhí)行了V操作，但是既然進了臨界區(qū)就總有從臨界區(qū)退出而執(zhí)行V操作的時候。這樣，一個線程在P操作以后總是有個V操作。從總體上看，每個線程的P操作和V操作是平衡的、即數(shù)量相等的。但是“事件”則不同，“事件”并不是用來構(gòu)筑臨界區(qū)、而純粹是用于線程間同步的。在這里，等待事件發(fā)生的一方總是執(zhí)行P操作，而發(fā)出事件通知的一方則總是執(zhí)行V操作。在前面對于“信號量”的比喻中把P操作比作領(lǐng)取通行證，把V操作比作交還通行證。相比之下，對于“事件”則相當(dāng)于領(lǐng)取的通行證從來不交還，而另有供應(yīng)者在不時地提供新的通行證。而且，特別有意義的是，發(fā)出事件通知的一方還不必非得是一個線程，也可以是內(nèi)核中的某些子系統(tǒng)，例如設(shè)備驅(qū)動，所以也可以用于線程與內(nèi)核之間的同步，特別是廣泛地應(yīng)用于設(shè)備驅(qū)動。當(dāng)然，發(fā)出事件通知的一方更不必局限于某一個特定的線程，而是任何一個線程都可以。
    為了幫助讀者加深對事件機制的理解，下面是一個內(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]

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

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

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

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

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

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