C++ 回调函数中正确的pthread_mutex_锁类型

我有一个经常从全局范围调用的第三方回调函数，为了同步缓冲区序列，我使用pthread_mutex_锁和pthread_mutex_ERRORCHECK类型

---

期望的行为是阻止对回调函数的每次调用，直到前一次调用的处理完成。我目前使用的互斥锁类型是否适用于此，因为我目前正在经历一个奇怪的系统锁定，操作完全冻结，并怀疑是我处理锁定错误后的代码导致了这种情况。按照设计，锁永远不会失效。

您的描述不太清楚。通常情况下，不会从“全局范围”调用对象，只会调用某些类型的构造函数和析构函数。也许您所说的是一个外部函数调用：回调由另一个软件组件中的某个外部上下文调用。您也没有明确说明谁在编写回调。这是第三方库调用您注册的回调吗？“第三方回调”是第三方库中的一个函数，它将自己注册为对您的回调

我将假设您正在调用某个第三方库，该库调用您的回调，并且您将在代码中或在第三方中陷入死锁状态

如果死锁发生在第三方代码中，可能您没有遵守回调可以做什么或不可以做什么的适当规则。您是否在回调中调用第三方代码？也许你不被允许这样做，或者某些人不允许这样做。也许第三方库在调用您的回调时持有一个互斥体，而您从该回调调用的函数试图获取相同的互斥体

如果死锁在您自己的代码中，在您自己的互斥体上，可能您正在做一些愚蠢的事情，比如持有互斥体，调用第三方代码，然后再次尝试锁定互斥体。如果是这么简单的话，有各种各样的方法。一个是在调用外部组件时永远不要保持互斥（这通常是个好主意，因为互斥应该保持很短的时间以避免争用）。在退出代码的过程中释放互斥锁，并在进入代码的过程中重新获取它。有时这是不方便的，因为每当您释放互斥时，“世界会发生变化”，您必须重新检查受保护变量的状态并处理可能发生的情况。bug可能会潜入其中，您的代码依赖于上一次持有互斥锁时的假设，而该假设由于释放互斥锁而不再适用

另一种可以处理这种回调情况的方法是让回调假设 确保互斥锁已被保持，并且不要将其锁定两次。如果回调函数是用作非回调函数的一般函数，请将其拆分为非锁定版本和锁定版本。将回调绑定到非锁定回调

另一件可能导致死锁的事情是以相反的顺序获取多个锁。当线程以不同的顺序遍历大程序的对象层次结构时，这很容易发生。例如，一些线程与调用对象B上的方法的对象A一起工作，而另一个线程正在执行从B到A的操作。在离开模块时始终释放锁的技术将有助于防止这种情况。在不能这样做的情况下，可以重构代码，使其始终以相同的顺序获取锁

---

另一个工具是不同种类的锁。递归锁可以提供帮助（尽管它们是一个难题）。读写锁在某些情况下会有所帮助。“无锁”算法（使用原子机器指令形式的微小互斥体，而不是大的操作系统互斥体）也是如此。

听起来互斥体应该在函数开始时锁定，然后在函数结束时释放。是这样吗？也许在程序的其他部分使用相同的互斥锁。另外，您可以粘贴用于锁定的代码以及代码中的错误处理和解锁部分吗？通过PTHREAD_MUTEX_ERRORCHECK，您可以检查互斥体是否被线程递归锁定。是吗？你查过了吗？是否存在无法解锁互斥锁的代码路径？你做了什么？你需要提供更多的信息，并且可能会显示一些代码，否则你甚至很难猜出什么是错的；但根据目前给出的信息，我看不到一个明显的方法来修正“猜测”。没有具体的代码，也没有更详细的场景描述，等等。有什么想法吗？我认为应该做的事情是在问题上添加一条评论，询问更多信息，并保存答案，直到有可能。。