[英]WaitForSingleObject - do threads waiting form a queue?
如果我設置3個線程來等待釋放互斥鎖,它們是否根據它們請求的順序形成隊列,或者它是未定義的行為(即我們不知道哪個將首先獲取它)?
它在SDK文章中明確記錄:
如果多個線程正在等待互斥鎖,則選擇等待線程。 不要假設先進先出(FIFO)順序。 內核模式APC等外部事件可以更改等待順序。
這些事件完全不受你的控制。 因此,“未定義的行為”是描述它的適當方式。
互斥對象基本上是公平的。 APC案件可能會發生,但並不常見。 特別是如果線程沒有執行I / O或正在使用完成端口或同步進行I / O.
大多數Windows用戶模式鎖(SRWLock,CriticalSection)如果你可以在沒有阻塞的情況下獲取它們是不公平的,但如果必須在內核中阻塞則是公平的。 這樣做的原因是為了避免鎖定車隊。 公平鎖定成為爭用的時刻,每個獲取者必須在獲得鎖定之前通過調度程序和上下文切換路徑。 沒有人可以“跳過去”而只是拿鎖,因為他們碰巧正在跑步。 因此,隊列中最后一個線程的鎖獲取時間通過隊列中每個先前線程的調度和上下文切換時間而增加。 在外部負載大部分被移除之前,系統不會從此狀態恢復,因為這是一個穩定的狀態。
對於性能,我建議使用上述用戶模式鎖之一,因為它們比內核互斥鎖快得多,如果它們適合您的場景。
喚醒訂單未定義,請參閱
關於這一點似乎有很多不同意見,而且沒有明確的信息。 在這個帖子中: http : //us.generation-nt.com/answer/are-events-fair-help-38447612.html有些人似乎建議使用忽略優先級的簡單fifo隊列來實現事件的公平性,同時其他人則說不應該假設公平。
最重要的是,我認為你最好不要將你的邏輯建立在公平性上,或者用你自己的實現包裝事件來保證公平。
是的,只有一個線程會被喚醒並鎖定互斥鎖。 但訂單未定義。
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.