如何避免由睡眠線程鎖定（擁有）的互斥鎖上的許多線程鎖定？

Question

這個問題稱為Convoying ：如果由於時間片中斷或頁面錯誤而對持有鎖的線程進行了調度，則所有其他線程都必須等待。 https://zh.wikipedia.org/wiki/Lock_(computer_science)#缺點

眾所周知，如果線程1鎖定了std::mutex並發生了線程1的切換，並且如果此時許多線程（2、3、4 ...）想要鎖定該互斥鎖，則所有這些線程都將被鎖定並將等待打開線程1。

解決方案是使用無鎖算法。 但是，如果需要使用互斥鎖，那是避免這種情況的解決方案嗎？

1. 在即將進行線程切換之前，如何預先找出100個周期？

2. 或者如何在Linux x86_64上切換流之前提前100個周期引發異常？

3. 或者如何使線程繼續工作一段時間（100個周期）？

更新：

我有20個CPU內核，我的程序有40個線程，該線程除以2部分：

• 第1部分 -20個線程使用受std::mutex mtx1保護的第一共享資源
• 第2部分 -20個線程使用受std::mutex mtx2保護的第二個共享資源

眾所周知，操作系統會為每個線程分配一定的工作時間，在此之后會使他平靜下來，並為下一個將在同一時隙運行的線程提供空閑的內核。

第1部分：有時（不是經常），但這種情況對我來說很關鍵，發生20個線程中的1個執行mtx1.lock()然后開始使用共享資源，然后在完成之前先關閉該線程的操作系統（使系統進入睡眠狀態） mtx1.unlock() -因為操作系統分配給該線程的時間已到期，操作系統決定讓該線程進入睡眠狀態。 並且OS僅在〜1-10ms（3000萬個周期）之后才打開該線程。 在這段時間內，Part-1的其他19個線程至少一次嘗試獲取10 mtx1 （30000個周期）中的每個共享資源，但是mtx1忙。

然后， 第1部分的19個線程中的每個線程開始入睡，騰出的CPU內核被第2部分中的線程占用。 操作系統發現所有內核都在忙，並且沒有喚醒Part-1的線程。

這種情況並不經常發生，但是當發生這種情況時，Part-1（20個線程）將凍結整個1-10毫秒（3000萬個周期），這對於任務來說是非常不可接受的。

第一部分延遲超過10微秒（3萬個周期）的情況怎么可能呢？

Answer 1

無鎖或近鎖設計的要點是，如果確實需要互斥鎖，那么某些東西將很少見，因此，任何兩個線程同時命中同一互斥鎖的可能性很小。 。

您對設計的解釋和准備采取的對策聽起來像您認為所有線程都很有可能會碰到互斥鎖-因此您的想法是錯誤的或設計是錯誤的。

您無法做任何事情來了解調度程序的思想，但是正如此處所討論的，您可以做些可能會影響您的線程 調度方式的事情-但是我建議您不要嘗試任何類似的事情。