pthread_cond_signal死锁

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

据我所知（ 手册页 ），它是用一个互斥体内部实现的，但是什么可能导致这个内部互斥锁操作发生死锁？

编辑：我正在debugging一些应用程序，似乎在某些情况下的死锁。 一些堆栈跟踪看起来像这样：

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

处于睡眠状态的cpu利用率较高

不同的UTF-8签名相同的变音符（元音变音） – 2种二元方式来编写变音符号

套接字select中可能的死锁原因

需要帮助来debugging互斥锁死锁

与pthreads和CreateThread的死锁

pthread_cond_signal导致死锁

有没有办法解决由第三方库引起的OS加载程序锁死锁？

Linux中的raw_spin_lock是否禁用hrtimer中断？

信号/暂停死锁

如何在Linux中摆脱僵局

那么，有一点可以从手册页中找到这个警告，这听起来特别适用：

条件函数不是异步信号安全的，不应该从信号处理程序调用。 特别是，从信号处理程序中调用pthread_cond_signal或pthread_cond_broadcast可能会导致调用线程死锁。

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