提升共享互斥锁检查是否锁定在同一个线程中答案

【问题标题】：boost shared mutex check if locked in the same thread提升共享互斥锁检查是否锁定在同一个线程中
【发布时间】：2015-03-26 17:13:34
【问题描述】：

当我编写多线程算法时，我发现有些方法对预期互斥锁的状态很有用。有些人已经锁定了，有些人还没有。

我想出了如何断言互斥锁是否已经被锁定的方法：

ASSERT(!mutex.try_lock_shared()); // assert if the mutex is not uniquely locked

ASSERT(!mutex.try_lock()); // assert if the mutex is not at least shared locked

问题是我如何才能断言检查互斥锁是否未锁定......从当前线程。例如，如果我这样做

     if (mutex.try_lock()) {
        mutex.unlock();
     } else {
        ASSERT(false); // the mutex is locked
     }

它显然有时会失败，只是因为其他线程已锁定它。

【问题讨论】：

“我正在用很多方法相互调用来扭曲非常复杂的多线程算法。” - 我可以在这里给出的最好建议是：让它更简单。只需将其分解为更高级别的步骤，以便您在精神上负责锁定。递归互斥锁几乎总是一种代码味道。就像共享指针一样，它们被过度使用，而不是考虑您的设计以使其变得简单。
“非常复杂”是我做完所有这些后达到的状态。当我明确要求 shared_mutex 时，我不确定为什么每个人都认为我要问的是与可重入互斥锁有多大关系。我想要的就像每个优秀的开发人员所做的那样，当我指定方法期望时，而不是评论，我能够添加一个断言，以便在某些事情违反协议时更快地弄清楚。
我明白了。只是当您无法解释（以何种方式）您的特定应用程序很复杂时，这让我认为可能存在一些设计债务。否则，我看不出在问题中提到这种所谓的复杂性是如何具有建设性/相关性的。如果您不希望这与此有任何关系，则可以将其从问题中删除
不知道为什么你会发现它有害，但我摆脱它，因为你是对的，它也没有贡献。
只需编写您自己的互斥锁，这些互斥锁恰好具有您想要的行为。您可以使用常规互斥锁来实现它们以保护它们的内部状态。例如，您的“锁定”函数可以首先锁定常规互斥体，然后将“持有此锁定的人”变量设置为当前线程的标识符。这使得断言起作用。

标签： c++ multithreading boost boost-mutex

【解决方案1】：

boost 具有递归和非递归互斥锁。如果函数是可重入的，请使用递归互斥锁。那么你就不用担心当前线程是否已经锁定了。

【讨论】：

我不想重新进入互斥锁。锁定互斥锁将指示错误。我希望尽快收到信号，表明我的逻辑有误。
尝试使用带有标志的递归互斥锁。递归互斥锁将允许您在同一个线程上多次锁定。该标志将表示它之前是否被锁定。比如：boost::recursive_mutex::scoped_lock l(mtx_); if (flag_) { // handle error } flag_ = true; ...