问题标签 [recursive-mutex]

POSIX 允许互斥体是递归的。这意味着同一个线程可以两次锁定同一个互斥体并且不会死锁。当然也需要解锁两次，否则其他线程无法获得互斥量。并非所有支持 pthread 的系统也支持递归互斥锁，但如果它们想要符合 POSIX 标准，它们必须.

其他 API（更高级的 API）通常也提供互斥锁，通常称为锁。一些系统/语言（例如 Cocoa Objective-C）同时提供递归和非递归互斥锁。有些语言也只提供一种或另一种。例如，在 Java 中，互斥锁总是递归的（同一个线程可能在同一个对象上“同步”两次）。根据它们提供的其他线程功能，没有递归互斥锁可能没有问题，因为它们可以很容易地自己编写（我已经在更简单的互斥锁/条件操作的基础上自己实现了递归互斥锁）。

我不太明白：非递归互斥锁有什么用？如果它两次锁定同一个互斥锁，为什么我会想要一个线程死锁？即使是可以避免这种情况的高级语言（例如测试这是否会死锁并抛出异常）通常也不会这样做。他们会让线程死锁。

这仅适用于我不小心将其锁定两次并且仅将其解锁一次的情况，并且在递归互斥锁的情况下，将更难找到问题，因此我立即将其死锁以查看不正确的锁定出现在哪里？但是我不能在解锁时返回一个锁计数器做同样的事情吗？在我确定我释放了最后一个锁并且计数器不为零的情况下，我可以抛出异常或记录问题吗？还是我没有看到其他更有用的非递归互斥锁用例？或者它可能只是性能，因为非递归互斥体可能比递归互斥体稍微快一点？但是，我对此进行了测试，差异确实没有那么大。

pthreads 是否支持任何允许您查询递归互斥锁已锁定次数的方法？

我在 SO 上阅读了这个答案：

因为递归互斥体有归属感，所以抓取互斥体的线程必须是释放互斥体的同一个线程。在非递归互斥锁的情况下，没有所有权感，任何线程通常都可以释放互斥锁，无论哪个线程最初获取互斥锁。

我对最后的陈述感到困惑。一个线程可以锁定一个互斥锁，而另一个不同的线程可以解锁该互斥锁吗？我认为同一个线程应该是唯一能够解锁互斥锁的线程？或者是否有任何特定的互斥锁允许这样做？我希望有人能澄清一下。

我了解递归互斥锁允许互斥锁多次锁定而不会陷入死锁，并且应该解锁相同的次数。但是在什么特定情况下需要使用递归互斥锁呢？我正在寻找设计/代码级别的情况。

我有一个自定义类，它使用像这样的增强互斥锁和锁（仅相关部分）：

如果我尝试从同一个线程多次锁定对象，我会得到一个异常（lock_error）：

这是输出：

为什么会这样？我是否错误地理解了某些概念？

我在下面的代码中遇到错误。

导致此错误的原因是什么？

我想知道佛罗里达州立大学的 pthread 标准实现是否能够处理递归互斥锁。不幸的是，关于 FSU 实现的文档相当差，并且没有提到将互斥体声明为递归的可能性或不声明。

尝试如下声明互斥锁：

并使用 FSU pthreads 库进行编译，我得到了以下错误列表：

尝试在我的机器上使用（非 FSU）pthread 实现编译相同的代码，它可以工作。

为了避免琐碎，我提前告诉您，默认情况下，POSIX 互斥锁不是递归的。

我是否应该得出结论，没有办法在 FSU 实现中使用递归互斥锁，还是有另一种方法来实现这些（即另一种将互斥锁声明为递归的方法）？

调用unlock()a后boost::recursive_mutex::scoped_lock，锁对象会在其析构函数中以某种方式引用互斥锁吗？

在调用解锁后，锁仍然保留对互斥锁的引用（即mutex()返回相同的指针）。release()如果互斥体在锁超出范围之前被销毁，还必须在锁上调用吗？

我对如何使用 pthread 声明递归互斥锁有点困惑。我尝试做的是一次只有一个线程能够运行一段代码（包括函数），但在怀疑之后我发现使用互斥锁不起作用，而我应该使用递归互斥锁。这是我的代码：

所以我尝试做的只是从队列中连续读取/删除。

问题是没有任何关于如何声明递归互斥锁的例子。或者可能有一些，但他们不为我编译。

condition_variable_any与 a 一起使用时recursive_mutex，在等待时通常recursive_mutex可以从其他线程获取吗？我对 Boost 和 C++11 的实现都感兴趣。condition_variable_any::wait

这是我主要关心的用例：