（这个问题可能与pthread_exit in signal handler causes segmentation fault有些相关）我正在编写一个引导锁定预防库，其中总是有一个检查线程正在执行图形内容并检查是否存在死锁，如果有，则表示其中一个冲突的线程。当该线程捕获信号时，它释放它拥有并退出的所有互斥锁。有多个资源互斥（显然）和一个关键区域互斥，所有获取，释放资源锁定和执行图形计算的调用必须首先获得此锁定。现在出现了问题。使用2个竞争（不计入检查线程）线程，有时程序在一个线程被杀死后死锁。在gdb中，它说死线程拥有关键区域锁定但从未释放它。在信号处理程序中添加断点并单步执行后，在pthread_exit（）之前看起来锁属于其他人（正如预期的那样），但是在pthread_exit（）之后，所有权神奇地转到了这个线程。
我能想到的唯一猜测是，当试图获得关键区域锁定时，被杀死的线程在pthread_mutex_lock处阻塞（因为它需要另一个资源互斥锁），然后信号来了，中断了pthread_mutex_lock 。由于这个电话不是信号防范的，所以发生了一些奇怪的事情？就像信号处理程序可能已经返回并且该线程获得锁定然后退出？ Idk ..非常感谢任何见解！
答案 0 :(得分：3)
pthread_exit不是异步信号安全的，因此您可以从信号处理程序调用它的唯一方法是确保信号不会中断任何非异步信号安全功能。 / p>
作为一般原则，使用信号作为与线程通信的方法通常是一个非常糟糕的主意。你最终混合了两个本身已经很难的问题：线程安全（线程之间的正确同步）和单个线程内的重入。
如果您的信号目标只是指示线程终止，则更好的机制可能是pthread_cancel。但是，为了安全地使用它，将被取消的线程必须在适当的位置设置取消处理程序和/或在不安全时暂时取消取消（使用pthread_setcancelstate）。另请注意，pthread_mutex_lock不是取消点。有一种没有安全方法来中断被阻塞等待获取互斥锁的线程，所以如果你需要这样的可中断性，你可能需要一个更精细的同步设置和条件变量（condvar等待是可以取消的），或者您可以使用信号量而不是互斥量。
编辑：如果你确实需要一种方法来终止等待互斥锁的线程，你可以用调用你自己的函数来调用pthread_mutex_lock来调用pthread_mutex_timedlock并在每次超时时检查退出标志。