在我的代码中，如果我的线程在调用 .ReleaseMutex() 之前多次调用 .WaitOne() 会很方便。

反之亦然：调用 .ReleaseMutex() 几次，然后重新启动以调用 .WaitOne() 开始的循环。

一些操作系统/编译器组合允许这样做。有些没有。

除了PTHREAD_RECURSIVE_MUTEX_INITIALIZER 和 PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP 之间的区别是什么？

我想知道这两者之间的其他区别是什么。

我有以下多态接口：

的一些实现service是同步的：

其他是异步的：

我需要创建一个service包装器，它service本身就是一个。这需要是线程安全的并在 a 下保持一些状态mutex：

如果_underlying->connect调用始终是异步的，则std::mutex可以正常工作。但是，在_underlying->connect同步的情况下，程序将冻结。

这可以通过使用std::recursive_mutexinstead of来解决std::mutex，但众所周知这是代码异味。

这是一个有效的用例std::recursive_mutex吗？

还是设计有缺陷？请注意，我无法控制service界面。

我从各种来源（ 1、 2 ）听说应该避免使用递归互斥锁，因为这可能是黑客或糟糕设计的标志。但是，有时我认为它们可能是必要的。鉴于此，以下是递归互斥锁的合适用例吗？

编辑：

我想用一个简单的例子来问这个问题，但也许它太简单了。这就是我想象的更现实的场景：我有一个堆栈数据结构，可以被多个线程访问。特别是，有时一个线程会从堆栈中弹出 n 个元素，但它必须一次全部完成（中间没有另一个线程从堆栈中压入或弹出）。设计问题的关键是我是否应该让客户端自己管理使用非递归互斥锁锁定堆栈，或者让堆栈提供同步的、简单的方法以及递归互斥锁，客户端可以使用这些方法进行多个原子事务也是同步的。

C++ 线程 A 是否可以通过将“暂停”P 存储在一个对象中来暂停其执行，然后该对象可以在另一个线程 B 中使用以在线程 A 中运行函数 F？

B 可以使用 P 来解锁 A 拥有的互斥锁。或者 F 可以锁定已经被 A 锁定的递归互斥锁，这可以安全地完成（与只有当您有回调时的递归锁定方案一样安全），因为：

• 这个过程纯粹是合作的
• 真正的 A 没有运行，而 F run be B 在“A 中”运行，所以只有一个执行有锁

[当然，当以一种无序的方式完成时，它显然是不安全的，就像在进行任意回调时持有的任何递归锁一样（不知道锁已经被持有并且误解了能够锁定，认为互斥锁没有被锁定）或非递归互斥体（可能会尝试锁定已锁定的互斥体和死锁或导致错误），或者本质上涉及在使用锁调用的回调中等待资源的任何场景。]

因为线程不能与自身并行运行，所以 A 只能在 P 被销毁后重新启动。

这里的重点是操作系统不应该参与其中，只有 C++ 运行时：F 会立即在操作系统线程 B 中运行，而不是被安排执行。操作系统线程 B 仍将运行，但作为线程 A 执行。

换句话说，C++ 线程能否以合作的方式交换身份？

我正在尝试启动递归互斥锁但无法成功。这是我的代码：

在 printf 我总是得到

死锁或活锁的类型为 0。

即互斥锁在调用 pthread_mutexattr_settype() 后保持 PTHREAD_MUTEX_DEFAULT

从 main() 调用的包装函数。

这是调用前的代码：

有什么建议么？

我正在使用 ROS（机器人操作系统）框架。如果您熟悉 ROS，在我的代码中，我没有使用活动服务器。简单地使用发布者、订阅者和服务。不幸的是，我面临 pthread_recursive_mutex 错误的问题。以下是错误及其回溯。

如果有人熟悉 ROS 堆栈，您能否分享一下可能导致此运行时错误的潜在原因？

我可以提供有关我的运行时错误的更多信息。非常感谢帮助。谢谢

设计：

• 包含'recursive'互斥体资源的单例。
• 2 个线程使用这个单例来更新/管理数据。
• 无论哪个线程首先尝试访问它，都会创建单例。
• 单例创建具有全局锁以确保我们只调用mutex attr init一次mutex init。

示例代码：两个线程具有相同的流程（只是不同的数据）并且会首先调用 funcX()

instance() 内部有一个全局互斥锁（），以确保只创建 A 的 1 个实例。它还在锁定后不久进行附加（！_instance）检查，以确保我们不会再次创建实例。

问题：

很少，第一个互斥锁调用不会增加the __count(0)变量。尽管__owner (thread id), __nusers (1),__lock (2)属性都已更新。每当我尝试记录__kind属性时，问题都不会发生。

初步发现：

当问题发生时，两个线程都在尝试初始化单例（也是互斥体）。由于单例创建中的全局锁，只有 1 个线程继续创建互斥体并将其初始化为recursive类型。那么锁定互斥量的线程正在查看过期的内存并导致认为互斥量类型是正常的？__kind = 0. 互斥锁返回成功。并且当调用随后的 unlock 时，互斥锁类型现在被更新recursive，因为pthreadunlock 没有 0 检查，它最终递减__countto be INT_MAX。

Unlock 也返回成功并且互斥锁永远不会被释放，导致另一个线程永远处于等待状态。

发生这种情况的可能原因是什么？可以__kind以某种方式损坏吗？

我正在使用在共享内存中定义的递归互斥锁用于两个进程之间的同步。我看到两个进程之间出现死锁，但是当我调试核心文件时，我发现进程 A 和进程 B 都没有拥有锁，但都试图获取锁。我们可以在下面看到，在这两个进程中，锁的所有者都是 0。

过程一：

过程乙：

这对我来说似乎很奇怪，我可以知道你的第一个想法是什么吗？

有人可以给我一些关于它的信息吗？

我有一个核心转储文件，其中pthread_mutex_destroy()返回了错误，可能是因为在pthread_mutex_t数据结构中该__nusers字段设置为 4294967295 (0xFFFFFFFF)。以下是完整值：

这是一个递归互斥锁。该代码在 RHEL 8 系统上运行。

因此，乍一看，这看起来像是__nusers以某种方式经常减少一次。但我不明白这是怎么发生的——pthread_mutex_unlock()在没有锁定的情况下调用首先将__nusers计数保留为 0（它返回EPERM，但递归互斥体不应该涉及任何未定义的行为）。

在什么情况下会__nusers变成本质上的“消极”？