移交鎖定的std :: unique_lock新線程

看看下面的例子，我創建一個std::mutex，將其鎖定，然後用手將鎖定到另一個線程：移交鎖定的std :: unique_lock新線程

#include <future> 
#include <mutex> 

int main() 
{ 
    // Create and lock a mutex 
    std::mutex mutex; 
    std::unique_lock<decltype(mutex)> lock(mutex); 

    // Hand off the lock to another thread 
    auto promise = std::async(std::launch::async, 
     [lock{ std::move(lock) }]() mutable 
     { 
      // Unlock the mutex 
      lock.unlock(); 
     }); 

    promise.get(); 

    return 0; 
}

的例子似乎運行正常用gcc 6.3，但運行時斷言與Visual Studio 2015錯誤「解鎖無主互斥體」。

我注意到，如果我切換示例使用std::shared_timed_mutex和std::shared_lock，那麼該示例將成功完成。我也注意到，如果我刪除了明確的unlock，那麼該示例成功完成，但互斥鎖似乎根本不能解鎖（如果我嘗試再次鎖定互斥鎖，gcc會崩潰，gcc不會抱怨）。

基於我在cppreference.com上閱讀的關於std::unique_lock的內容，在我看來，原始示例應該運行良好。如果另一個線程執行了lock，std::mutex或std::unique_lock是否禁止線程爲unlock？這可能是一個VC錯誤？

來源

2017-05-26 François Andrieux

它與'std :: unique_lock'不相關，它只是調用互斥體上的鎖定/解鎖，而不是互斥體本身。 – Slava

根據http://en.cppreference.com/w/cpp/thread/mutex/unlock：

互斥量必須執行的當前線程被鎖定，否則，行爲是不確定的。

std::shared_timed_mutex::unlock()的文檔具有相同的規格，因此不保證可以與該類一起使用。

來源

2017-05-26 17:56:53

我會使用不同的單詞而不是「不保證工作」 – Slava

@FrançoisAndrieux最有可能你有XY問題 – Slava

@Slava我通過對'async'函數傳遞一個互斥體的引用並從那裏取得另一個鎖來解決這個問題。如果有人竊取了互斥鎖之間的關係，那就好了，只是覺得你知道你馬上需要解鎖互斥鎖就像是一種浪費。我只是好奇，爲什麼原來的方法不起作用。 –

移交鎖定的std :: unique_lock新線程

回答

相關問題