操作系统概念（第七章）死锁

男娘i 2022-08-14 04:55 373阅读 0赞

# 死锁 #

所有申请的资源都被其他等待进程占有，那么该等待进程有可能在无法改变其状态，这种情况称为**死锁（deadlock）**。

## 系统模型 ##

进程在使用资源之前必须先申请资源，在使用资源之后要释放资源。进程所申请的资源数量不能超过系统所有资源的总量。

在正常操作模式下，进程只能按如下顺序使用资源：

*  ①申请：如果申请不能立即被允许，那么申请进程必须等待，直到它获得该资源为止。
 *  ②使用：进程对资源进行操作。
 *  ③释放：进程释放资源

资源的申请与释放为系统调用。其他资源的申请与释放可以通过信号量的wait与signal操作或通过互斥锁的获取与释放来完成。因此对于进程和线程的每次使用，操作系统会检查以确保使用进程已经申请并获得了资源。

系统表记录了每个资源是否空闲或已被分配，分配给了哪个进程。如果进程正在申请的资源正在为其他进程所使用，那么该进程会增加到该资源的等待队列。

当一组进程的每个进程都在等待一个事件，而这个事件只能由这一组进程的另一个进程所引起，那么这组进程就处于死锁状态。

死锁也可设计不同的资源类型。多线程可能因为竞争共享资源而容易产生死锁。

## 死锁特征 ##

当出现死锁时，进程永远不能完成，并且系统资源被阻碍使用，阻止了其他作业开始执行。

### 必要条件 ###

如果在一个系统中下面四个条件同时满足，那么会引起死锁。

（1） 互斥(mutual exclusion)：至少有一个资源必须处于非共享模式，即一次只有一个进程使用，如果另一个进程申请该资源，那么申请进程必须等到该资源被释放为止。

（2） 占有并等待(hold and wait)：一个进程必须占有至少一个资源，并等待另一资源，而该资源为其他进程所占有。

（3） 非抢占(no preemption)：资源不能被抢占，即资源只能在进程完成任务后自动释放。

（4） 循环等待(circular wait)：有一组等待进程｛P0,P1,P2,P3…,Pn｝,P0等待的资源被P1等待，P１等待的资源被P2所占有，……，Pn−1等待的资源为Pn所占有，Pn所等待的资源被P0所占有。

４个条件必须同时满足才会出现死锁，循环等待条件意味着占有并等待条件，这样四个条件并不完全独立。

### 资源分配图 ###

死锁问题可用称为系统资源分配图的有向图进行更为精确地描述。

这种图由一个节点集合Ｖ和一个边集合Ｅ组成。节点集合Ｖ可以分成两种类型的节点：

Ｐ＝｛P1，P2，…，Pn｝（系统活动进程的集合）

Ｒ＝｛R1，R2，…，Rn｝（系统所有资源的集合）

Pi→Rj 表示进程Pi已经申请了资源类型为Rj的一个实例，称为申请边

Rj→Pi表示资源类型Rj已经分配给进程Pi，称为分配边

如一个分配图的例子如下：

![20150618220007769][]  
有一个  R1、R3 的资源，有两个  R2 的资源，有三个  R4 的资源。

可以证明：

如果分配图没有环，那么系统就没有进程死锁。如果分配图有环，那么可能存在死锁。

如果每个类型只有一个实例，环是死锁存在的充分必要条件。不过每个类型不止一个实例，环是死锁的必要条件。  
存在死锁的资源分配图：

![20150619091448022][]  
存在环但是没有死锁的资源分配图  
![20150619091508488][]

## 死锁处理方法 ##

有三种方法：

1.  可使用协议以预防或避免死锁，确保系统不会进入死锁状态。
2.  可允许系统进入死锁状态，然后检测它，并加以修复。
3.  可忽略这个问题，认为死锁不可能在系统内发生。

这里第三种方法为绝大多数操作系统所用，因此应用程序开发人员需要自己来处理死锁。

为了确保死锁不会发生，系统可以采用死锁预防或死锁避免方案

**死锁预防（deadlock prevention）**是一组方法，以确保至少一个必要条件不成立。这些方法通过限制如何申请资源的方法来预防死锁。

**死锁避免（deadlock avoidance）**要求操作系统事先得到有关进程申请资源和使用资源的额外信息。有了这些额外信息，系统可以确定：对于一个申请，进程是否应等待。为了确定当前申请是允许还是延迟，系统必须考虑可用资源，已经分配给每个进程的资源，每个进程将来申请和释放的资源。

除此之外，系统还可以提供一个算法来检查系统状态来确定死锁是否发生，并提供另一个算法来从死锁中恢复。

预防死锁的副作用是降低设备的使用率和系统的吞吐率。

缺点是低设备使用率和系统吞吐率。

## 死锁预防（deadlock prevention） ##

出现死锁有四个必要条件，只要保证至少一个条件不成立，就能预防死锁的发生。

### 互斥 ###

对于非共享资源，必须要有互斥条件（如打印机）。另一方面，共享资源不要求互斥访问，因此不会涉及死锁（如只读文件）。

故通常不能通过否定互斥条件来预防死锁，有的资源本身就是非共享的。

### 占有并等待 ###

为了确保占有并等待条件不会在系统内出现，必须保证：**当一个进程申请一个资源时，就不能占有其他资源**。

*  方法一：可以使用的协议是每个进程在执行前申请并获得所有资源。通过要求申请资源的系统调用在所有其他系统调用之前进行。
 *  方法二：允许进程在没有资源时才可申请资源，一个进程可申请一些资源并使用它们，然而，在它申请更多其他资源之前，它必须释放其现已分配的所有资源。

这两种协议有两个主要缺点：

*  第一，资源利用率（resource utilization）可能比较低，因为很多资源可能已分配，但长时间没有被使用。
 *  第二，可能发生饥饿。一个进程如需要多个常用资源，可能会永久等待，比如因为其所需要的资源中至少一个总是分配给其他的进程。

### 非抢占 ###

为确保这一条件不成立，可使用如下协议：

即可以抢占，如果一个进程占用资源并申请另一个不能立即分配的资源，那么其现已分配的资源都可被抢占，即这些资源被隐式地释放了。只有当进程获得其原有资源和所申请的新资源时，进程才可以重新执行。

或者说，如果一个进程申请一些资源，首先检查是否可用，如果可用就分配它们，如果不可用，那么检查这些资源是否已分配给其他等待额外资源的进程。如果是就抢占这些资源，并分配给申请进程。如果资源不可用且也不可被其他等待进程占有，那么申请进程必须等待。当一个进程处于等待时，如果其他进程申请其拥有的资源，那么该进程部分资源可以被抢占。一个进程要重新执行，他必须分配到其所申请的资源，并恢复其在等待时被抢占的资源。

这个协议通常用于状态可以保存和恢复的资源，如CPU寄存器和内存，一般不适用其他资源，如打印机和磁带驱动器。

### 循环等待 ###

一个确保此条件不成立的方法是：对所有资源类型进行完全排序，且要求每个进程按递增顺序来申请资源。

设Ｒ＝｛R1，R2，R3，…，Rn｝为资源类型的的集合。为每个资源类型分配一个唯一整数来允许比较两个资源以确定其先后顺序。可定义一个函数Ｆ：R→N ,其中Ｎ是自然数集合，例如：

Ｆ（tapedrive）＝1Ｆ（diskdrive）＝5Ｆ（printer）＝12

每个进程只按照递增顺序申请资源，即一个进程开始可以申请任意数量的资源类型为  Ｒｉ 的实例。之后，当且仅当  Ｆ（Rj）>Ｆ（Ri） 时，该进程可以申请资源Rj的实例。如果需要同一资源类型的多个实例，那么对它们必须一起申请。

例如，对于以上给定函数，一个进程如果同时需要打印机和磁带驱动器，那么就必须先申请磁带驱动器，再申请打印机。换句话说，要求当一个进程申请资源类型Rj时，必须先释放所有Ri\[Ｆ（Ri）>Ｆ（Rj）\]

可以使用反证法证明，使用这两个协议，那么循环等待就不可能成立。

设计一个完全排序或层析并不能防止死锁，而是要靠应用程序员来按顺序编写程序。另外函数Ｆ应该根据系统内资源使用的正常顺序来定义。例如，由于磁带通常在打印机之前使用，所以定义Ｆ（tapedrive）<Ｆ（printer）较为合理。

## 死锁避免（deadlock-avoidance） ##

避免死锁的另外一种方法是获得以后如何申请资源的附加信息。

不同的算法所要求的信息量和信息的类型上有所不同，最为简单和最为常用的模型要求每个进程说明可能需要的每种资源类型实例的最大需求。根据每个进程可能申请的每种资源类型实例的最大需求的事先信息，可以构造一个算法以确保系统绝不会进入死锁状态。这种算法定义了**死锁避免（deadlock-avoidance）方法**。

死锁避免算法动态地检测资源分配状态以确保循环等待条件不可能成立。资源分配状态是由可用资源和已分配资源，以及进程最大需求所决定的。

### 安全状态 ###

**如果系统能按某个顺序为每个进程分配资源（不超过其最大值）并能避免死锁，那么系统状态就是安全的。**即如果存在一个安全序列，那么系统处于安全状态。如果没有这样的顺序存在，那么系统处于不安全状态。

进程顺序\{ P1,P2,…,Pn\}，如果对于每个Pi，Pi仍然可以申请的资源数小于当前可用资源加上所有进程Pj（其中j小于i）所占用资源，那么这一顺序称为安全序列。

在这种情况下，进程Pi所需要的资源即使不能立即使用，那么Pi等待直到所有Pj释放其资源，当它们完成时，Pi可得到其所需要的所有资源，完成其给定任务。

安全状态不是死锁状态，相反，死锁状态是不安全状态。然而，不是所有不安全状态都能够导致死锁状态。

只要状态为安全，操作系统就能避免不安全（和死锁）状态。在不安全情况下，操作系统不能阻止进程以会导致死锁的方式申请资源。进程行为控制了不安全状态。

![20150619210218567][]  
例如考虑一个系统，有  12 台磁带驱动器和三个进程  P0,P1,P2 ,目前状况如下表：

顺序｛P1，P0，P2｝满足安全条件，因为：

*  对于P1,2小于3
 *  对于P0,5小于等于2\+3
 *  对于P2,7小于5\+2\+3

系统可以从安全状态转变为不安全状态，加入某时刻，进程P2申请并又得到了一台磁带驱动器，系统就不再安全了。

此时P0还需要5台，但是系统只剩４台了，必须等待，同时P2还需要６台，也必须等待，由此导致了死锁。

造成这个错误的原因即允许P2再获取了一台磁带驱动器。

有了安全状态的概念，可定义避免算法确保系统不会死锁，即确保系统处于安全状态，开始，系统处于安全状态，当进程申请一个可用资源时，系统必须确定这一资源申请是可以立即分配还是要等待，即便现在资源可用，也只有分配后系统仍处于安全状态，才允许申请。

也因此采用这种方法和没有采用死锁避免算法相比资源使用率可能更低。

### 资源分配图算法 ###

利用资源分配图，引入需求边Pi→Rj表示进程Pi可能在将来某个时候申请资源Rj。只有申请边变为分配边而不会导致资源分配图形成环时，才允许申请。

如果没有环存在，那么会使得系统处于安全状态，如果有环存在则分配会导致系统处于不安全状态。

例如：

![20150619221107539][]  
假如进程  P2 申请资源  R2 。虽然  R2 现在可用，但是不能分配给  P2 ，因为这会创建一个环，环表示系统处于不安全状态，如果  P1 再申请  R2 就会造成死锁。

### 银行家算法 ###

银行家算法：对于每种资源类型有多个实例的资源分配系统，资源分配图就不再适用。使用银行家算法，但是效率比资源分配图方案低。

当新进程进入系统时，它必须说明其可能需要的各种类型资源实例的最大数量，这一数量不能超过当前系统资源的总和。当用户申请一组资源时，系统必须确定这些资源的分配是否仍会使系统出于安全状态，如果是，就分配资源；否则，进程必须等待直到某个其他进程释放足够资源为止。

实现银行家算法，必须有几个数据结构：**Available，Max，Allocation，Need**。

这些数据结构对资源分配系统的状态进行了记录。设ｎ为系统的进程的个数，ｍ为资源类型的种类：

**Available**：长度为m的向量，表示每种资源类型的现有实例的数量。如果Available\[j\] = k，则说明资源类型Rj有现有ｋ个实例。

**Max**：ｎ×ｍ矩阵，定义每个进程的最大需求，如果Max\[ｉ\]\[ｊ\] = k，那么进程Pi最多申请ｋ个资源类型R\+j的实例。

**Allocation**：ｎ×ｍ矩阵，定义每个进程现在所分配的各种资源类型的实例数量，例如Allocation\[ｉ\]\[ｊ\]　= k，那么进程Pi现在已经分配了ｋ个资源类型Rj的实例。

**Need**：ｎ×ｍ矩阵，表示每个进程还需要的剩余的资源。如果Need\[ｉ\]\[ｊ\] = k，那么进程Pi还需要申请ｋ个资源类型Rj的实例。并且Need\[ｉ\]\[ｊ\] = 　Max\[ｉ\]\[ｊ\]　 - Allocation\[ｉ\]\[ｊ\]

这些数据结构的大小和值会随着时间而改变。

为了简化银行家算法的描述：

设Ｘ，Ｙ为长度为n的向量，那么X≤Y 当且仅当对所有的i=1,2,3…,n，X\[i\]≤Y\[i\]，如果X≤Y 并且Ｘ!=Ｙ,那么Y小于X。

可以将矩阵Allocation 和Need的每行作为向量，并分别用Allocationi 和Needi来表示。

向量Allocationi表示分配给进程Pi的资源，Needi表示进程Pi为完成其任务可能仍然需要申请的额外资源。

### 安全性算法 ###

确定计算机是否处于安全状态需要以下几步：

*  1 创建Work 和 Finish 向量，长度分别为m,n，并且Work = Avallable，将Finish的每一项置为false
 *  2 查找是否存在这样的i使得满足：
    
    Finish\[i\] = false
    
    Needi <= Work

如果不存在则跳到第四步。

*  3
    
    Work = Work + Allocationi
    
    Finish\[i\] = true

跳回第二步

*  4 如果对所有的ｉ，Finish\[i\] = true,那么系统处于安全状态。

### 资源请求算法 ###

设Requesti为进程Pi的请求向量。即如果`Requesti[j]==k` ，那么Pi所需要资源类型Rj的实例数量为k。

当进程Pi做出资源申请时，采取如下动作：

*  1 如果Requesti<Needi，那么进行下一步，否则产生出错条件，因为已经超过了其最大请求。
 *  2 如果Requesti<Available，那么进行下一步，否则Pi必须等待，因为没有可用的资源。
 *  3 假定系统可以分配给进程Pi所需的资源，并按如下方式修改状态：

Available=Available−Requesti

Allocationi=Allocationi\+Requesti

Needi=Needi−Requesti

如果所产生的资源分配状态是安全的，那么交易完成且进程Pi可分配到其所需要的资源。

然而，如果新状态不安全，那么进程Pi必须等待Requesti并回复到原资源分配状态。

举例

假定系统中有4个进程P1、P2、P3、P4和3种类型的资源R1、R2、R3，数量分别为9、3、6，在t0时刻的资源分配情况如表所示。

t0时刻的资源分配表：

![20150709113815393][]

试问：

（1）t0时刻是否安全？

（2）P2发出请求向量Request2（1，0，1），系统能否将资源分配给它？

（3）在P2申请资源后，若P1发出请求向量Request1（1，0，1），系统能否将资源分配给它？

（4）在P1申请资源后，若P3发出请求向量Request3（0，0，1），系统能否将资源分配给它？

解答：

（1）安全序列：P2、P1、P3、P4

（2）可以分配，因为分配资源后可找到一安全序列：P2、P1、P3、P4

（3）不能分配，因为request1(1,0,1)＞available(0,1,1)

（4）不能分配，因为分配资源后找不到一安全序列。

## 死锁检测 ##

检测和恢复都会有额外的开销：这不仅包括维护所需信息和执行检测算法的运行开销，而且也包括死锁恢复所引起的损失。

### 情况一：每种资源类型只有单个实例： ###

该算法使用了资源分配图的变种，等待（wait-for）图。从资源分配图中，删除所有资源类型节点，合并适当边，就可以得到等待图。等待图中由Pi到Pj的边意味着进程Pi等待进程Pj释放一个Pi所需的资源。

当且仅当等待图中有环，系统中存在死锁。为了检测死锁，系统需要维护等待图，并周期性调用在图中进行搜索的算法。从图中检测环的算法需要n2级别操作，其中n为图中的节点数。

### 情况二：每种资源类型可有多个实例： ###

采用与银行家算法相类似的算法。

Available：长度为m的向量，表示各种资源的可用实例。

Allocation：ｎ×ｍ矩阵，表示当前各进程的资源分配情况。

Request：ｎ×ｍ矩阵，表示当前各进程的资源请求情况。如果Request\[ｉ\]\[ｊ\] = k，那么Pi现在正在请求k个资源Rj。

1 创建Work 和 Finish 向量，长度分别为m,n，并且Work = Avallable，将Finish的每一项置为false

2 查找是否存在这样的i使得满足：

Finish\[i\] = false

Requesti <= Work

如果不存在则跳到第四步。

Work = Work + Allocationi

Finish\[i\] = true

跳回第二步

4 如果对所有的ｉ，Finish\[i\] == false,那么系统处于死锁状态。而且进程Pi死锁

### 应用检测算法 ###

极端情况下，在每次请求分配不能立即允许时，就调用死锁检测算法。但会引起相当大的计算开销。或以一个不太高的频率调用检测算法，但这通常不能确定死锁进程中哪些“造成”了死锁。

## 死锁恢复 ##

一种措施是通知操作员死锁已发生，以便操作人员人工处理死锁。

另一种措施是让系统从死锁状态中自动恢复过来。打破死锁有两种方法：一个方法是简单地终止或多个进程以打破循环等待。

另一个方法是从一个或多个死锁进程那里抢占一个或多个资源。

### 进程终止： ###

一是，终止所有死锁进程，这种方式虽然终止了死锁循环，代价太大。

二是，一次只终止一个进程直到取消死锁循环为止，这种方法的开销会很大，因为每次终止一个进程，就需要调用死锁检测算法以确定进程是否仍处于死锁。

### 资源抢占： ###

这里有三个问题需要处理：

①选择一个牺牲品：抢占哪些资源和哪个进程？必须确定抢占顺序以使代价最小化。

②回滚：如果从一个进程那里抢占一个资源，那么应对该进程做些什么安排？必须将这个进程回滚到某个安全状态，以便以后重启进程。

最简单的方法是完全回滚：终止进程并重新执行。更为有效的方法是将进程回滚到足够打破死锁。另一方面，这种方法要求系统维护有关运行进程状态的更多信息。

③饥饿：如何确保不会发生饥饿？最为常用的方法是在代价因素中加上回滚次数。

[20150618220007769]: /images/20220731/73640acd15ad47b99132aa0bb4412fca.png
[20150619091448022]: /images/20220731/22a96a34022841659625b54ed24dfa02.png
[20150619091508488]: /images/20220731/6d41a9a2d89345c7992017586b81ac6f.png
[20150619210218567]: /images/20220731/502c6df251f444f1be1fb632e1aedb81.png
[20150619221107539]: /images/20220731/ee986c6dbf80402fa8dcc2ab2fb3c1c8.png
[20150709113815393]: /images/20220731/7a984f017b4d42ff9039d2fb50f5265c.png