递归锁（互斥锁）与非递归锁（互斥锁）

Question

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

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

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

这是否仅适用于我不小心锁定它两次而只解锁一次的情况，并且在递归互斥体的情况下，更难找到问题，所以我立即将其死锁以查看错误锁定出现的位置？ 但是，我不能在解锁时返回一个锁计数器吗？在我确信我释放了最后一个锁并且计数器不为零的情况下，我可以抛出异常或记录问题吗？ 或者还有其他我看不到的更有用的非递归互斥体用例吗？ 或者这可能只是性能问题，因为非递归互斥体可能比递归互斥体稍快一些？ 不过我测试了一下，差别确实没有那么大。

Answer 1

递归互斥体和非递归互斥体之间的区别与所有权有关。 在递归互斥体的情况下，内核必须跟踪第一次实际获得互斥体的线程，以便它可以检测递归与应该阻塞的不同线程之间的差异。 正如另一个答案指出的那样，在存储此上下文的内存以及维护它所需的周期方面都存在额外开销的问题。

但是，这里还有其他考虑因素。

因为递归互斥体具有所有权意识，所以抓取互斥体的线程必须与释放互斥体的线程是同一个线程。 在非递归互斥体的情况下，没有所有权意识，任何线程通常都可以释放互斥体，无论哪个线程最初获取互斥体。 在许多情况下，这种类型的“互斥体”实际上更像是一种信号量操作，您不一定将互斥体用作排除设备，而是将其用作两个或多个线程之间的同步或信号设备。

互斥体中具有所有权感的另一个属性是支持优先级继承的能力。 由于内核可以跟踪拥有互斥锁的线程以及所有阻塞程序的身份，因此在优先级线程系统中，可以将当前拥有互斥锁的线程的优先级升级为最高优先级线程的优先级当前正在互斥体上阻塞。 这种继承可以防止在这种情况下可能发生的优先级反转问题。 （请注意，并非所有系统都支持此类互斥体的优先级继承，但这是通过所有权概念成为可能的另一个功能）。

如果您参考经典的 VxWorks RTOS 内核，它们定义了三种机制：

• 互斥 - 支持递归和可选的优先级继承。 此机制通常用于以一致的方式保护数据的关键部分。
• 二进制信号量 - 无递归，无继承，简单排除，接受者和给予者不必是同一线程，可用广播发布。 此机制可用于保护关键部分，但对于线程之间的一致信号或同步也特别有用。
• 计数信号量 - 无递归或继承，充当任何所需初始计数的连贯资源计数器，线程仅在资源净计数为零的情况下阻塞。

同样，这会因平台而有所不同 - 特别是他们对这些东西的称呼，但这应该代表正在发挥作用的概念和各种机制。

Answer 2

答案是不是效率。 不可重入互斥体可以产生更好的代码。

示例：A::foo() 获取锁。 然后它调用 B::bar()。 当你写的时候这个效果很好。 但过了一段时间，有人将 B::bar() 更改为调用 A::baz()，这也获取了锁。

好吧，如果没有递归互斥锁，就会陷入僵局。 如果你有它们，它会运行，但可能会损坏。 A::foo() 在调用 bar() 之前可能使对象处于不一致的状态，假设 baz() 无法运行，因为它也获取了互斥体。 但它可能不应该运行！ 编写 A::foo() 的人假设没有人可以同时调用 A::baz() - 这就是这两个方法获取锁的全部原因。

使用互斥体的正确思维模型：互斥体保护不变量。 当互斥体被持有时，不变量可能会改变，但在释放互斥体之前，不变量会被重新建立。 可重入锁很危险，因为第二次获取锁时，您无法再确定不变式是否正确。

如果您对可重入锁感到满意，那只是因为您以前没有调试过这样的问题。 顺便说一句，Java 现在在 java.util.concurrent.locks 中具有不可重入锁。

Answer 3

正如 Dave Butenhof 本人所写：

“递归的所有大问题中最大的一个互斥体是
他们鼓励你完全忘记你的锁定方案并且
范围。 这是致命的。 邪恶的。 这就是“吃线者”。 你持有锁的目的是
绝对是最短的时间。 时期。 总是。 如果你打电话
仅仅因为您不知道它已被持有而被锁定的东西，或者
因为你不知道被调用者是否需要互斥锁，那么你就是
持有时间太长。 您将霰弹枪瞄准您的应用程序并且
扣动扳机。 您可能开始使用线程来获取
并发； 但你刚刚阻止了并发。”

Answer 4

正确的使用心理模型
互斥体：互斥体保护
不变。

为什么您确定这确实是使用互斥体的正确思维模型？
我认为正确的模型是保护数据而不是不变量。

即使在单线程应用程序中，保护不变量的问题也存在，并且与多线程和互斥体没有共同之处。

此外，如果您需要保护不变量，您仍然可以使用从不递归的二进制信号量。

Answer 5

递归互斥体有用的一个主要原因是在同一线程多次访问方法的情况下。 例如，如果互斥锁保护银行账户提款，那么如果还存在与该提款相关的费用，则必须使用相同的互斥锁。

Answer 6

递归互斥体唯一好的用例是当一个对象包含多个方法时。 当任何方法修改了对象的内容时，因此必须锁定对象才能使状态再次一致。

如果方法使用其他方法（即：addNewArray（）调用addNewPoint（），并用recheckBounds（）完成），但任何这些函数本身都需要锁定互斥体，那么递归互斥体是双赢的。

对于任何其他情况（解决只是错误的编码，甚至在不同的对象中使用它）显然是错误的！

Answer 7

恕我直言，大多数反对递归锁（我在 20 年的并发编程中 99.9% 的时间都使用递归锁）的争论都将递归锁的好坏与其他软件设计问题混为一谈，而这些问题是完全无关的。 举个例子，“回调”问题，它被详尽地阐述，没有任何多线程相关的观点，例如在书中 组件软件 - 超越面向对象编程。

一旦出现一些控制反转（例如事件触发），您就会面临重入问题。 与是否涉及互斥体和线程无关。

class EvilFoo {
  std::vector<std::string> data;
  std::vector<std::function<void(EvilFoo&)> > changedEventHandlers;
public:
  size_t registerChangedHandler( std::function<void(EvilFoo&)> handler) { // ...  
  }
  void unregisterChangedHandler(size_t handlerId) { // ...
  }
  void fireChangedEvent() { 
    // bad bad, even evil idea!
    for( auto& handler : changedEventHandlers ) {
      handler(*this);
    }
  }
  void AddItem(const std::string& item) { 
    data.push_back(item);
    fireChangedEvent();
  }
};

现在，使用上面这样的代码，您可以获得所有错误情况，这些情况通常在递归锁的上下文中命名 - 只是没有任何错误情况。 事件处理程序一旦被调用就可以自行取消注册，这会导致简单编写的 fireChangedEvent() 中出现错误。 或者它可能会调用 EvilFoo 的其他成员函数，从而导致各种问题。 根本原因是重新进入。
最糟糕的是，这甚至可能不是很明显，因为它可能会在整个事件链上触发事件，最终我们又回到了 EvilFoo（非本地）。

所以，重入才是根本问题，而不是递归锁。
现在，如果您觉得使用非递归锁更安全，那么这样的错误会如何表现出来呢？ 每当发生意外重新进入时就会陷入僵局。
并带有递归锁？ 同样，它会在没有任何锁的代码中体现出来。

因此，EvilFoo 的邪恶部分是事件及其实现方式，而不是递归锁。 对于初学者来说，fireChangedEvent() 需要首先创建 changedEventHandlers 的副本，并将其用于迭代。

经常讨论的另一个方面是锁首先应该做什么的定义：

• 保护一段代码不被重新进入
• 保护资源不被同时使用（被多个线程使用） ）。

我进行并发编程的方式，我有后者的心理模型（保护资源）。 这是我擅长递归锁的主要原因。 如果某个（成员）函数需要锁定资源，它就会锁定。 如果它在执行其操作时调用另一个（成员）函数，并且该函数也需要锁定 - 它就会锁定。 而且我不需要“替代方法”，因为递归锁的引用计数与每个函数编写的内容完全相同：

void EvilFoo::bar() {
   auto_lock lock(this); // this->lock_holder = this->lock_if_not_already_locked_by_same_thread())
   // do what we gotta do
   
   // ~auto_lock() { if (lock_holder) unlock() }
}

一旦事件或类似的构造（访问者？！）开始发挥作用，我就会这样做不希望通过某种非递归锁来解决所有随之而来的设计问题。

Answer 8

非递归互斥体有什么用处？

当您在执行某些操作之前必须确保互斥锁已解锁时，它们绝对是很好的选择。 这是因为pthread_mutex_unlock可以保证互斥体只有在非递归的情况下才被解锁。

pthread_mutex_t      g_mutex;

void foo()
{
    pthread_mutex_lock(&g_mutex);
    // Do something.
    pthread_mutex_unlock(&g_mutex);

    bar();
}

如果 g_mutex 是非递归的，则上面的代码保证在互斥体解锁的情况下调用 bar()。

因此，如果 bar() 碰巧是一个未知的外部函数，该函数很可能会执行某些操作，从而导致另一个线程尝试获取相同的互斥锁，从而消除了死锁的可能性。 这种情况在基于线程池构建的应用程序和分布式应用程序中并不罕见，其中进程间调用可能会产生一个新线程，而客户端程序员甚至没有意识到这一点。 在所有此类场景中，最好仅在释放锁后才调用所述外部函数。

如果g_mutex是递归的，则根本没有办法在调用之前确保它已解锁。