揭開條件背後的秘密：notify_one()加鎖或不加鎖

問題：

為了確保高效率的線程協調，std::condition_variables發揮關鍵作用。然而，在呼叫notify_one()之前取得鎖的必要性存在不確定性：它是強制性的，還是可選的做法？

解開謎團：

答案很明確：在呼叫notify_one()之前並沒有強制要求持有鎖。然而，在某些情況下，取得鎖是一種好的做法。讓我們深入研究一下這背後的原因。

為什麼要鎖？

• 悲觀方法：雖然持有鎖看起來多餘，這可以被認為是一種悲觀策略。透過在通知等待執行緒之前釋放鎖，被通知的執行緒將立即嘗試重新取得它。這可能會導致爭用和潛在的效能下降，因為兩個執行緒都競爭相同的資源。
• 維護一致性：某些用例要求嚴格遵守條件變數使用指南。在整個更新和等待操作過程中持有鎖可確保鎖所保護的資料的一致性。這種做法可以最大限度地減少競爭條件或資料損壞的風險。

範例：兩個通知的故事

提供的範例提出了有關不一致鎖定的問題後續notify_one() 所調用的行為。初始呼叫沒有鎖的原因是後面的等待操作：等待函數將自動取得和釋放鎖，確保被通知的執行緒可以繼續執行。然而，後續的notify_one()呼叫會受到鎖的保護，因為它們不涉及等待操作。

總而言之，在呼叫notify_one()之前持有鎖定並不是普遍要求，但這是建議的做法某些場景。它可以減輕潛在的效能問題並確保資料完整性。