pthread_cond_signal 死锁答案

【问题标题】：pthread_cond_signal deadlockspthread_cond_signal 死锁
【发布时间】：2010-12-03 12:02:13
【问题描述】：

如果对pthread_cond_signal 的调用出现死锁，可能是什么原因？

据我了解 (man page)，它是在内部使用互斥锁实现的，但什么可能导致此内部互斥锁锁定操作死锁？

编辑：我正在调试一个在某些情况下似乎死锁的应用程序。一些堆栈跟踪如下所示：


Thread 1 (Thread 0xf6dff6c0 (LWP 32001)):
#0  0xffffe410 in __kernel_vsyscall ()
#1  0x00af15de in __lll_mutex_lock_wait () from /lib/tls/libpthread.so.0
#2  0x00aef3eb in pthread_cond_signal@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0
#3  0xf4cc8d83 in xxx

【问题讨论】：

这是一种假设，还是您实际看到这种情况发生？
我正在调查一个 Linux 应用程序中的实际死锁情况。
不要只显示该线程在做什么，而是所有线程都在做什么：thread apply all backtrace。只使用一个线程不会导致死锁。
我同意你的观点，这个问题并不是关于死锁的原因，我更一般地问什么可能导致 pthread_cond_signal 阻塞。我现在无法访问调试器，但我相信另一个线程正在执行 pthread_cond_wait。

标签： linux pthreads deadlock

【解决方案1】：

嗯，要寻找的一件事可能是手册页中的这个警告，这听起来特别适用：

条件函数不是异步信号安全，不应该从信号处理程序中调用。在特别是，调用 pthread_cond_signal 或 pthread_cond_broadcast 来自一个信号处理程序可能会使调用死锁线程。

除此之外，如果pthread_cond_t 中的内部互斥体已被超出某个其他变量范围的杂散写入覆盖，您也可以看到这一点。

【讨论】：

谢谢，是的，我开始怀疑内存损坏了。我将检查是否从信号处理程序中使用了任何 pthread* 函数。