pthread_cond_signal 死锁
如果调用 pthread_cond_signal 发生死锁，可能会是什么原因？
据我了解（手册页），它是在内部使用互斥体实现的，但是什么会导致内部互斥锁操作死锁吗？
编辑：我正在调试一个在某些情况下似乎陷入僵局的应用程序。一些堆栈跟踪如下所示：
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
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?
EDIT: 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
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
好吧，需要注意的一件事可能是手册页中的这一警告，这听起来特别适用：
除此之外，如果 pthread_cond_t 中的内部互斥锁已被超出某些其他变量范围的杂散写入覆盖，您也可能会看到这一点。
Well, one thing to look for might be this caveat from the man page, which sounds particularly applicable:
Apart from that, you could also see this if the internal mutex within the
pthread_cond_thas been overwritten by a stray write beyond the bounds of some other variable.