我正在Ubuntu上用C进行编码。 我有两个以上这样的线程：
void * thread(void)
{
retry:
pthread_mutex_lock(&mutex);
//DO SOMETHING
pthread_mutex_unlock(&mutex);
goto retry;
}
所以我有thread1，thread2，...，threadN。 有时可以使用pthread_cancel（）从 thread1 中杀死 thread2，...，threadN 。
此pthread_cancel（）插入互斥锁内，因此在安全区域中调用。
每次thread1在threadK上调用pthread_cancel时，pthreadK都在等待互斥量，因此他调用了函数pthread_mutex_lock（）。
这东西会在我的程序中造成问题吗？ 我的程序中有一个错误，我认为我有一个死锁，但是我不明白为什么。我在想这就是原因。
谢谢大家。
如果可以避免，请不要使用线程取消。有很多问题和难题需要解决。
一类问题与资源清理有关。尽管POSIX定义了一种注册清理处理程序的机制来解决此问题，但是要确保所有资源（分配的内存，打开的文件，互斥量和信号量，常规的共享状态）都能够被正确清理，需要花费大量的心血。手段。例如，一个线程很容易无法解除取消锁定时被锁定的互斥锁，从而死锁每个随后无条件尝试锁定它的线程。
另一个更微妙的问题类别与线程实际可以取消的时间点有关。默认情况下，具有挂起取消信号的线程将在下一个到达取消点时或已经在取消点处被阻塞时终止。相当数量的POSIX功能肯定是或可能是取消点，但不是全部。
尤其是pthread_mutex_lock() is not a cancellation point。因此，如果您取消pthread_mutex_lock中阻塞的线程，则不会立即取消该线程。原则上，它可能会成功锁定互斥锁，然后继续进行直到到达取消点为止，或者它可能返回而未锁定互斥锁（返回码为非零，以指示错误的性质）。两者都会给您带来麻烦，但是前者似乎特别准备让您陷入僵局。在实践中，pthread_mutex_lock()被记录为 not 返回EINTR，这使我期望将显示前一种选择：取消请求不会导致{{1 }}终止而无需获取互斥体并返回。