微軟有一個很有意思的同步對象，某種程度上和Linux的條件變量很相似。但秉承微軟一貫的作風，有些地方設計的又有點怪異。Event通過函數CreateMutex創建，可以分爲手動模式和自動模式兩種模式，兩種模式下表現迥異。和其他同步對象一樣，在WaitForSingleObject或者WaitForMultipleObjects等待激發。激發（取消激發）法有3個函數SetEvent，ResetEvent，PulseEvent根據模式不同給出說明如下表
HANDLE CreateEvent(
LPSECURITY_ATTRIBUTES lpEventAttributes,// 安全屬性
BOOL bManualReset,// 復位方式
BOOL bInitialState,// 初始狀態
LPCTSTR lpName // 對象名稱
);
// 函數介紹：創建一個事件內核對象，當該事件內核對象爲受信狀態時，所以所有等待該事件內核對象的線程都會被喚醒，以繼續做接下來的工作。若該事件內核對象爲未(非)受信狀態時，所以所有等待該事件內核對象的線程都會陰塞阻塞等待(當然設置了不等待屬性的除外)。
// 第一個參數(LPSECURITY_ATTRIBUTES lpEventAttributes)爲事件內核對象的安全屬性(指針)，一般情況爲NULL，我對此也不瞭解，所以不做評論
// 第二個參數(BOOL bManualReset) 復位方式，事件內核對象有兩種狀態，一個是受信狀態，一個是未(非)受信狀態。當事件爲受信狀態時所有等待該事件(一般爲函數：WaitForSingleObject()
)的線程都會被喚醒(從阻塞狀態激活)；反之，它將一般一直阻塞等到該事件爲受信狀態。若該參數爲TRUE， 則需要使用ResetEvent() 函數來重置該事爲未(非)受信狀態，否則該事件將永遠爲受信狀態；若該參數爲FALSE， 則一但有一個線程被喚醒，則該事件馬上會被置爲未(非)受信狀態。這使得其它也等待該事件的線程無法被喚醒。
BOOL ResetEvent(HANDLE hEvent);// 這個函數把指定的事件對象設置爲未(非)受信狀態。
BOOL SetEvent(HANDLE hEvent);// 這個函數把指定的事件對象設置爲受信狀態。
// 第三個參數(BOOL bInitialState)初始狀態，若爲TRUE， 新建出來的事件內核對象將是受信狀態，否則爲未(非)愛信狀態。
// 第四個參數(LPCTSTR lpName)對象名稱。指定事件的對象的名稱，是一個以0結束的字符串。名稱的字符格式限定在MAX_PATH之內。名字是對大小寫敏感的。
如果lpName指定的名字，與一個存在的命名的事件對象的名稱相同，函數將請求EVENT_ALL_ACCESS來訪問存在的對象。這時候，由於bManualReset和bInitialState參數已經在創建事件的進程中設置，這兩個參數將被忽略。如果lpEventAttributes是參數不是NULL，它將確定此句柄是否可以被繼承，但是其安全描述符成員將被忽略。
如果lpName爲NULL，將創建一個無名的事件對象。
如果lpName的和一個存在的信號、互斥、等待計時器、作業或者是文件映射對象名稱相同，函數將會失敗，在GetLastError函數中將返回ERROR_INVALID_HANDLE。造成這種現象的原因是這些對象共享同一個命名空間。
// 關閉事件內核對象，釋放資源
BOOL CloseHandle(HANDLE hObject);
相關函數：
DWORD WINAPI SignalObjectAndWait (__in HANDLE
hObjectToSignal, __in HANDLE hObjectToWaitOn,
__in DWORD dwMilliseconds, __in BOOL bAlertable);