導致 C++11 std::mutex 將阻塞的線程鎖定為被動等待狀態？

Question

我有以下情況：

兩個 C++11 線程正在進行計算，它們通過 std::mutex 進行同步。

線程 A 鎖定互斥鎖，直到數據為線程 B 執行的操作做好准備。 當互斥鎖被解鎖時，線程 B 開始工作。

線程 B 嘗試鎖定互斥鎖並被阻塞，直到被線程 A 解鎖。

void ThreadA (std::mutex* mtx, char* data)
{
    mtx->lock();
    //do something useful with data
    mtx->unlock();
}

void ThreadB (std::mutex* mtx, char* data)
{
    mtx->lock(); //wait until Thread A is ready
    //do something useful with data
    //.....
}

斷言線程 A 可以先阻塞互斥鎖。

現在我想知道線程 B 中的mtx->lock()是主動等待還是被動等待。 線程 B 輪詢互斥鎖狀態並浪費處理器時間或在互斥鎖解鎖時被調度器被動釋放也是如此。

在不同的 C++ 參考文獻中只提到線程被阻塞，但沒有提到以何種方式阻塞。

然而， std::mutex實現是否幾乎不依賴於使用的平台和操作系統？

Answer 1

它是高度實現定義的，即使對於相同的編譯器和操作系統

例如，在 VC++ 上，在 Visual Studio 2010 中， std::mutex是用 Win32 CRITICAL_SECTION實現的。 EnterCriticalSection(CRITICAL_SECTION*)有一些不錯的特性：首先它嘗試通過一次又一次地迭代鎖定來鎖定CRITICAL_SECTION 。 在指定的迭代次數后，它進行內核調用，使線程進入睡眠狀態，只有在釋放鎖並重新開始整個交易時才會再次被喚醒。 在這種情況下，該機制在進入睡眠之前一次又一次地輪詢鎖，然后控制權切換到內核。

Visual Studio 2012 帶有不同的實現。 std::mutex是用 Win32 互斥std::mutex實現的。 Win32 互斥鎖立即將控制權轉移到內核。 鎖沒有進行主動輪詢。

您可以在答案中閱讀有關實現開關的信息： std::mutex performance 與 win32 CRITICAL_SECTION 相比

因此，互斥鎖如何獲取鎖是不確定的。 最好不要依賴這種行為。

附： 不要手動鎖定互斥鎖，而是使用std::lock_guard 。 此外，您可能希望使用condition_variable來控制同步的更精細方法。