现代操作系统：死锁（二）

3.2 Ignoring the Problem—The Ostrich Algorithm忽略死锁之鸵鸟算法

俗称摆烂，就是不管，把头埋进沙子里。

如果进程发生死锁可能性足够小，并且为了避免死锁会付出很大的代价，那么忽略这个问题可能会更好。例如，如果一个PC操作系统每10年死锁一次，那么一次重启可能会比防止它所需要的限制少一些痛苦。

• 很明显，鸵鸟算法不适用于核导弹发射器或心脏护理单元的患者监测系统。
• 对于嵌入式系统（如上面的两个例子），要运行的程序是预先知道的，所以在Linux、MacOS或Windows等系统中出现的许多问题（例如，许多进程想要同时fork）并不会发生在嵌入式系统中。

3.3 Deadlock Detection and Recovery死锁的检测和恢复

3.3.1 Detecting Deadlocks with One Resources of Each Type每种类型一个资源的死锁检测

在本小节中，我们考虑一个特殊情况，即每个资源只有一个实例。即假设系统中有打印机、扫描仪，那么每种设备只会有一个，不会存在两个打印机的情况。

        因此，一个请求只能由一个特定的资源来满足，在这种情况下形成死锁的四个必要条件是充分的，肯定可以形成死锁。但是请记住，我们做的假设（单个单位资源）通常是无效的。例如，许多系统有多个打印机，请求的是一台打印机，而不是特定的打印机。类似地，一个人可以有许多CD-ROM驱动器。在那些更一般的情况下，Coffman-Havender条件是必要的，但不是充分的。

        在上述特殊情况下，问题简化为在资源分配图中找到一个有向循环。

Question：Why？

Answer：因为，如6.2.1节所述，我们所研究的系统总是满足基本的三个Coffman-Havender条件（因此我们只需要确定条件4是否满足），或者所研究的系统永远不满足（在这种情况下，死锁是不可能的）。也就是说，条件1 2 3是系统的静态条件，而不是系统当前状态的条件。正如我们在6.2.1中看到的，Havender-Coffman条件4中的链必须始终包含一个循环。

 

如何在有向图找到一个闭环？

在有向图中求有向环并不困难。算法在书里。这个想法很简单。

1. 对于图中的每个节点，进行深度第一次遍历，以查看该图是否为DAG（有向无循环图），在沿着DAG向下时构建一个列表（在往回回溯时修剪它）；DFS过程可DP提速。
2. 如果您曾经在列表中两次发现相同的节点，那么您已经发现了一个有向循环，图不是DAG，并且当前列表中的进程之间存在死锁；
3. 如果您从未两次找到相同的节点，则图为DAG，且不存在死锁(目前)；

搜索是有限的，因为节点的数量是有限的，如果你命中一个节点两次，你就会停止搜索。

3.3.2 Detecting Deadlocks with Multiple Unit Resources每种类型多个资源的死锁检测

 

这个情况就困难多了，上方的这张图表现了在每种类型存在多个资源的一种资源分配图。

• 每一个资源单位都被表示为方框中的蓝色点；
• 表示请求的边被绘制到与边框相连，因为它们表示对框中这一类资源的请求；
• 表示分配的边从每个资源单位点触发，连接到对应的进程；

在上图表示的资源分配中，即使明显看出了一个红色的有向循环，并且所有的资源单位都被分配，但是它并不会出现死锁。显然右侧的进程需要两个下方资源，当中间的进程运行完毕后会释放一个下方资源，然后右侧进程可以获得中间进程释放的资源后运行，从而解除当前的阻塞状态。实际上我们发现，在这个资源分配图中，至少有一个进程是可以运行的，并且当这个进程运行结束后可以解除其余进程的阻塞状态。

类似于图的拓扑排序算法

• 寻找一个可以终止的进程，也就是说该进程的所有请求连线都可以由管理员当前拥有的资源来满足；
• 如果找到这样一个进程，那就假装它已经运行结束了，然后擦除所有和他相连的弧；
• 如果有任何进程保留下来，它们就会陷入死锁，事实上，当我们开始算法时，它们已经是死锁状态了；
• 如果所有进程都可以被删除，那么说明当前资源依赖图中没有任何死锁。

 

我们将很快详细介绍一种算法（银行家算法），它具有很大的这种特点。

• 刚才给出的算法对非阻塞进程做出了最乐观的假设，它将返回所有资源并正常终止。如果我们发现仍然有被阻塞的进程，则这个闭环一定是死锁的；
• Bankers算法对非阻塞进程做出了最悲观的假设：他会立即请求所有可能请求的资源，在最悲观的假设下就可以有效避免死锁的发生。

3.3.3 Recovery from deadlock从死锁中恢复

Recovery through Preemption从抢占中恢复

也许您可以暂时从进程中抢占不可抢占的资源。不可能。

Recovery through Rollback通过回滚恢复

数据库（和其他）系统采用周期性的检查点，如果系统确实采用了检查点，则可以在检测到死锁时回滚到检查点。我们必须保证进程是向前推进的。

Recovery through Killing Processes通过杀死别的进程恢复

        总是可以做到的，但可能会很痛苦。例如，有些进程产生的影响是不能简单地消除的。打印、发射导弹等。

Note: 注意:我们在6.5之前做6.6，因为6.6更容易，我相信这是一个很好的热身。