c++ - 回调函数中正确的 pthread_mutex_lock 类型

Question

我有一个在全局范围内频繁调用的第三方回调函数，为了同步我的缓冲区序列，我使用类型为 PTHREAD_MUTEX_ERRORCHECK 的 pthread_mutex_lock

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

Answer 1

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

我假设您正在调用某个第三方库，它会调用您的回调，并且您将陷入死锁情况，无论是在您的代码中还是在第三方中。

如果死锁发生在第三方代码中，则可能您没有遵守回调可能执行或不执行的操作的正确规则。您是否在回调中调用第三方代码？也许你不被允许这样做，或者某些人不被允许这样做。也许第三方库在调用您的回调时持有互斥体，并且您从该回调调用的函数尝试获取相同的互斥体。

如果死锁发生在您自己的代码中，在您自己的互斥体上，也许您正在做一些愚蠢的事情，例如持有互斥体，调用第三方代码，然后尝试再次锁定互斥体。如果事情就这么简单，那么有多种方法。一是在调用外部组件时永远不要持有互斥锁(这通常是个好主意，因为互斥锁应该保留很短的时间以避免争用)。在退出代码时释放互斥锁，并在进入代码时重新获取它。有时这很不方便，因为每当您释放互斥锁时，“世界就会改变”，您必须重新检查 protected 变量的状态并处理可能发生的情况。错误可能会蔓延，您的代码依赖于上次持有互斥锁时的假设，但由于释放了互斥锁，该假设不再适用。

另一种可以处理这种回调情况的方法是让回调假设互斥体已经被持有并且不要锁定它两次。如果回调是一些也用作非回调的通用函数，请将其分为非锁定版本和锁定版本。将回调绑定(bind)到非锁定回调。

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

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