如何在UNIX上实际找到进程的死锁原因？

Question

在unix上，一个进程被卡住，你怀疑它可能是死锁，找到死锁的原因以及如何删除和避免它？

我知道死锁的4个条件：

1. 相互排斥：资源最多可以分配给一个进程（不共享）。

2. 保持并等待：允许持有资源的处理请求另一个。

3. 没有先发制人：进程必须释放其资源;他们不能被带走。

4. 循环等待：必须有一系列进程，以便链中的每个成员都在等待链的下一个成员持有的资源。

但是，它们是理论上的，如何确定unix实际上的死锁？ 只有看到一个过程没有取得进展？ 如何找到导致死锁的部分代码和原因？ 如果您被允许使用工具，可以使用什么？

感谢

Answer 1

还有Valgrind的Helgrind工具： Helgrind: a thread error detector

  

Helgrind是一个Valgrind工具，用于检测使用POSIX pthreads线程原语的C，C ++和Fortran程序中的同步错误。

     

POSIX pthreads中的主要抽象是：一组共享公共地址空间的线程，线程创建，线程连接，线程退出，互斥（锁），条件变量（线程间事件通知），读写器锁，自旋锁，信号量和障碍。

     

Helgrind可以检测到三类错误，这些错误将在接下来的三个部分中详细讨论：

     

  

1. Misuses of the POSIX pthreads API

  

2. Potential deadlocks arising from lock ordering problems

  

3. Data races -- accessing memory without adequate locking or synchronisation。

  

这些问题经常会导致无法重现的，与时间相关的崩溃，死锁和其他不当行为，并且很难通过其他方式找到。

Helgrind知道所有的pthread抽象并尽可能准确地跟踪它们的效果。在x86和amd64平台上，它理解并部分处理因使用LOCK指令前缀而产生的隐式锁定。

当您的应用程序仅使用POSIX pthreads API时，Helgrind效果最佳。但是，如果要使用自定义线程原语，可以使用helgrind.h中定义的ANNOTATE_ *宏来描述它们对Helgrind的行为。此功能已在Valgrind 3.5.0版中添加，并被视为实验性的。

Answer 2

使用调试器。

Quick tip for debugging deadlocks

或这个简单的：

how to find deadlock scenario using gdb