當我們調用 CreateEvent 函數創建一個事件對象的時候，我們可以通過參數來指定這個事件對象是自動重置的，還是手動重置的。

對于一個手動重置的事件對象，它很容易理解：當事件未激發時，在此事件上的等待將一直掛起，而當事件被激發時，在此事件對象上的等待將會立即返回。上面的工作原則和有多少個線程正在等待此對象沒有任何關系。所有線程對此對象的等待操作都是一致的，并且事件對象的狀態也不會受到等待它的線程數量影響。

對于一個自動重置的事件對象，事情開始變得復雜了。

理解它的工作原理的最簡單方法是：將它看做是一個最大計數為 1 的信號量。

此話怎講？

當事件未激發時，在此事件上的等待的線程將一直掛起，而當事件被激發時，僅會只有一個等待線程結束等待，并且事件對象將會自動重置其狀態為未激發態。結果就是：剩下的其他線程將會繼續等待。從我們之前對 PulseEvent 的討論來看，你可能已經知道了，如果有多個等待線程，則不確定將釋放哪個等待線程。

使用自動重置事件的陷阱在于：你設置了已處于激發態的事件。由于事件只有兩種狀態（設置和重置），因此設置已設置的事件不起作用。如果使用事件來控制資源生產者/使用者模型，則設置已處于激發態的事件將導致你看起來 “丟失:了令牌。

請考慮以下場景模式。

但是，如果時機沒有完全出來怎么辦？如果使用者線程完成工作有點慢（或者生產者線程生成它的速度有點快），該怎么辦：

請注意，生成者生成了三個工作項，但使用者只執行了其中的兩個。第三個 SetEvent 沒有效果，因為事件已經設置好了。（如果嘗試將信號量的令牌計數增加到超過其最大值，則會遇到相同的問題。)如果希望喚醒數與集數匹配，則需要使用最大令牌計數與將支持的最大未完成工作項數一樣高的信號量。

總結

了解你手上工具的使用方法，更加需要了解其局限性。永遠在正確的場景下使用正確的工具，這確實挺難的。