c++ - 取消锁定互斥量的线程不会解锁互斥量

Question

帮助客户解决他们遇到的问题。我更像是一名系统管理员/DBA，所以我正在努力帮助他们。他们说这是内核/环境中的错误，在我坚持认为它存在于他们的代码中或寻求操作系统的供应商支持之前，我试图证明或反驳这一点。

发生在 Red Hat 和 Oracle Enterprise Linux 5.7(和 5.8)上，应用程序是用 C++ 编写的

他们遇到的问题是主线程启动了一个单独的线程来执行可能长时间运行的 TCP connect() [客户端连接到服务器]。如果“长时间运行”方面花费的时间太长，他们会取消线程并启动另一个线程。

这样做是因为我们不知道服务器程序的状态:

• 服务器程序启动并运行 --> 立即接受连接
• 服务器程序未运行，机器和网络正常 --> 连接立即失败，错误为“连接被拒绝”
• 机器或网络崩溃或中断 --> 连接需要很长时间失败并出现错误“没有到主机的路由”

问题是取消锁定互斥量的线程(设置清理处理程序以解锁互斥体)有时不会解锁互斥体。

这使得主线程卡在尝试锁定互斥体上。

详细环境信息:

• glibc-2.5-65
• glibc-2.5-65
• libcap-1.10-26
• kernel-debug-2.6.18-274.el5
• glibc-headers-2.5-65
• glibc-common-2.5-65
• libcap-1.10-26
• kernel-doc-2.6.18-274.el5
• kernel-2.6.18-274.el5
• kernel-headers-2.6.18-274.el5
• glibc-devel-2.5-65

代码构建于:C++ -g3 tst2.C -lpthread -o tst2

非常感谢任何建议和指导

Answer 1

被取消的线程不会解锁它们持有的互斥锁是正确的，您需要手动安排它发生，这可能很棘手，因为您需要非常小心地在每个可能的取消点周围使用正确的清理处理程序。假设您正在使用 pthread_cancel 取消线程并使用 pthread_cleanup_push 设置清理处理程序来解锁互斥锁，您可以尝试几个可能更容易获得的备选方案正确，因此可能更可靠。

使用 RAII解锁互斥锁将更可靠。在 GNU/Linux 上，pthread_cancel 是通过 __cxxabi::__forced_unwind 类型的特殊异常实现的，因此当线程被取消时，将抛出异常并展开堆栈。如果互斥锁被 RAII 类型锁定，那么如果堆栈被 __forced_unwind 异常展开，它的析构函数将保证运行。 Boost Thread提供了一个可移植的 C++ 库，它包装了 Pthreads 并且更容易使用。它提供了 RAII 类型 boost::mutex 和其他有用的抽象。 Boost Thread也提供了自己的“线程中断”机制，与Pthread取消类似但不相同，Pthread取消点(如connect)不是Boost Thread中断点，这有助于一些应用程序。但是，在您的客户的情况下，由于取消点是中断 connect 调用，他们可能确实希望坚持使用 Pthread 取消。 GNU/Linux 将取消作为异常实现的(不可移植的)方式意味着它将与 boost::mutex 一起很好地工作。

当您用 C++ 编写代码时，确实没有任何借口明确地锁定和解锁互斥体，恕我直言，C++ 的最重要和最有用的特性是析构函数，它是自动释放资源的理想选择，例如互斥锁。

另一种选择是使用强大的互斥锁，它是通过调用 pthread_mutexattr_setrobust 创建的在初始化互斥量之前在 pthread_mutexattr_t 上。如果一个线程在持有一个健壮的互斥体时死亡，内核将记录下来，以便下一个尝试锁定互斥体的线程获得特殊错误代码 EOWNERDEAD。如果可能，新线程可以使线程保护的数据再次保持一致，并取得互斥体的所有权。这比简单地使用 RAII 类型来锁定和解锁互斥体更难正确使用。

一种完全不同的方法是在调用 connect 时决定是否真的需要持有互斥锁。在缓慢的操作期间持有互斥体不是一个好主意。您不能调用 connect 然后如果成功锁定互斥体并更新任何受互斥体保护的共享数据吗？

我的偏好是既使用 Boost Thread 又避免长时间持有互斥量。