移交锁定的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新线程

回答

相关问题