deadlock（解决死锁的方法）

本文目录

解决死锁的方法
如何解决Linux下信号产生的死锁
Java并发编程的线程死锁问题如何解决
死锁时为啥cpu很高，从内核角度分析一下

解决死锁的方法

一、解除死锁常常采用两种方法：1、资源剥夺法；2、撤消进程法。

二、处理死锁的思路如下：

预防死锁：破坏四个必要条件中的一个或多个来预防死锁。

避免死锁：在资源动态分配的过程中，用某种方式防止系统进入不安全的状态。

检测死锁：运行时产生死锁，及时发现思索，将程序解脱出来。

解除死锁：发生死锁后，撤销进程，回收资源，分配给正在阻塞状态的进程。

三、预防死锁的办法：

破坏请求和保持条件：

1、一次性的申请所有资源。之后不在申请资源，如果不满足资源条件则得不到资源分配。

2、只获得初期资源运行，之后将运行完的资源释放，请求新的资源。

破坏不可抢占条件：当一个进程获得某种不可抢占资源，提出新的资源申请，若不能满足，则释放所有资源，以后需要，再次重新申请。

破坏循环等待条件：对资源进行排号，按照序号递增的顺序请求资源。若进程获得序号高的资源想要获取序号低的资源，就需要先释放序号高的资源。

扩展资料

形成死锁的四个必要条件：

（1）互斥条件：一个资源每次只能被一个进程使用。

（2）请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。

（3）不剥夺条件:进程已获得的资源，在末使用完之前，不能强行剥夺。

（4）循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系。

如何解决Linux下信号产生的死锁

一次测试环境发生了server死锁，整个server的任务线程都被hang住。而死锁的代码就在我负责的程序日志部分中localtime_r函数调用处。

程序日记需要记录打印日志的时间，而localtime_r函数就是用于将系统时间转换为本地时间。同样功能的函数还有localtime。两个函数的区别是：localtime_r是thread-safe，其返回的结果存在由用户提供的buffer中；而localtime返回的结果是指向static变量，多线程环境可被其他线程修改。localtime_r实现中有一把锁，负责lock tzfile中的状态变量，而server就在这里发生死锁。

经过分析死锁是由于发kill信号，信号处理函数引起的。原线程打印程序日志获得localtime_r中需要的锁后，kill信号触发中断处理，正好分配给该线程处理中断。信号处理函数中再次打印日志，调用localtime_r的锁时发生死锁。

之前的信号处理方式为异步方式，同时信号处理函数中做了很多事情。之前大家一直关注线程安全，却从来没有注意过异步信号处理函数的安全性。这次最新版本由于还在开发中，大家调用了大量日志打印，增加了死锁的概率才将这个问题暴露出来。

##Signal Handling and Nonreentrant Functions

信号处理函数不推荐做太多工作，如果调用函数需要是reentrant。reentrant可重新进入的，可以理解为一次调用发生后，不会对该函数的再次调用发生任何影响。即reentrant函数中不可以有static或global变量，不可以分配释放内存，通常不可以使用修改用户提供的对象，修改errno等等。具体可以看同步信号处理