pthread_cond_signal死锁 [英] pthread_cond_signal deadlocks

问题描述

如果调用 pthread_cond_signal 死锁可能是什么原因？

What could be the cause if a call to pthread_cond_signal deadlocks?

根据我的理解（手册页），它是在内部使用互斥锁实现的，但是可能导致此内部互斥锁锁定的原因

From what I understand (man page), it is implemented internally with a mutex, but what could cause this internal mutex lock operation to deadlock?

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

I am debugging an application which seem to deadlock on some occasions. A few of the stacktraces look like this:

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

推荐答案

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

Well, one thing to look for might be this caveat from the man page, which sounds particularly applicable:

The条件函数不是
异步信号安全的，并且不应从信号处理程序中调用
。特别是在
中，从信号$ b调用
pthread_cond_signal 或
pthread_cond_broadcast $ b处理程序可能会死锁正在调用的
线程。

The condition functions are not async-signal safe, and should not be called from a signal handler. In particular, calling pthread_cond_signal or pthread_cond_broadcast from a signal handler may deadlock the calling thread.

除此之外，如果内部互斥量位于 pthread_cond_t 已被杂散写入所覆盖，超出了其他变量的范围。

Apart from that, you could also see this if the internal mutex within the pthread_cond_t has been overwritten by a stray write beyond the bounds of some other variable.

这篇关于pthread_cond_signal死锁的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！