boost 递归锁_C ++-作为类成员的std :: mutex与std ::递归互斥体

应将0设为默认值，将remove_one_node视为性能优化吗？

不是，不是 使用非递归锁的优点不仅在于性能优化，它还意味着您的代码正在自我检查叶级原子操作确实是叶级，它们不会调用其他使用该锁的东西。

在某种情况下，您会遇到以下情况：

一个实现一些需要序列化的操作的函数，因此它将使用互斥锁并执行该操作。

另一个函数，它实现较大的序列化操作，并希望在保持较大操作的锁的同时调用第一个函数来执行其中的一个步骤。

举一个具体的例子，也许第一个函数原子地从列表中删除一个节点，而第二个函数原子地从列表中删除两个节点(并且您永远不希望另一个线程看到仅使用两个节点之一的列表。 出来)。

为此，您不需要递归互斥体。 例如，您可以将第一个函数重构为一个公共函数，该公共函数获取锁定并调用一个私有函数，该私有函数“不安全地”执行该操作。 然后，第二个函数可以调用相同的私有函数。

但是，有时使用递归互斥锁比较方便。 这种设计仍然存在问题：0在类不变式不成立的时候调用remove_one_node(第二次调用它时，列表恰好处于我们不想公开的状态)。 但是，假设我们知道remove_one_node不依赖于不变式，这并不是设计中的致命错误，只是我们使规则比理想的“所有类不变式总是在任何公共函数中都成立”复杂一些。 输入”。

因此，该技巧偶尔会很有用，而且我不讨厌递归互斥体达到本文所能达到的程度。 我没有历史知识可以争辩说，将它们包含在Posix中的原因与文章所说的“演示互斥量属性和线程扩展”不同。 我当然不认为它们是默认值。

我认为可以肯定地说，如果在设计中不确定是否需要递归锁，那么您的设计就不完整。 稍后您会后悔一个事实，那就是您正在编写代码，并且您不知道根本上不重要的事情，例如是否允许已经持有该锁。 因此，请勿“以防万一”放置递归锁。

如果您知道需要一个，请使用一个。 如果您知道不需要一个锁，那么使用非递归锁不仅是一种优化，它还有助于强制执行设计约束。 第二个锁失效比成功并隐瞒您不小心做了设计中永远不应该做的事情这一事实要有用。 但是，如果按照您的设计进行操作，并且永远不会双重锁定互斥锁，那么您将永远不会发现它是否是递归的，因此递归互斥锁不会直接有害。

这个类比可能会失败，但是这是另一种看待它的方法。 想象一下，您可以在两种指针之间进行选择：一种在取消引用空指针时使用堆栈跟踪中止程序，另一种返回0(或将其扩展为更多类型：其行为就像指针指向一个值一样) -初始化的对象)。 非递归互斥锁有点像正在中止的互斥锁，而递归互斥锁有点像返回0的互斥锁。它们都有潜在的用途-人们有时会花一些时间来实现“安静而不是-a”。 -value”值。 但是，如果您的代码设计为从不取消引用空指针，则默认情况下，您不想使用默默允许发生这种情况的版本。