文章目录
3.6 预防死锁
预防死锁的方法是通过破坏产生死锁的四个必要条件中的一个或几个，以避免发生死锁。由于互斥条件是非共享设备所必须的，不仅不能改变，还应加以保证，因此主要是破坏产生死锁的后三个条件。
3.6.1 破坏"请求和保持"条件
为了能破坏“请求和保持”条件，系统必须保证做到：当一个进程在请求资源时，它不能持有不可抢占资源。该保证可通过如下两个不同的协议实现：
1.该协议规定，所有进程在开始运行之前，必须一次性地申请其在整个运行过程中所需的全部资源。
2.该协议是对第一种协议的改进，它允许一个进程只获得运行初期所需的资源后，便开始运行。
3.6.2 破坏"不可抢占"条件
为了能破坏“不可抢占”条件，协议中规定，当一个已经保持了某些不可被抢占资源的进程，提出新的资源请求而不能得到满足时，它必须释放已经保持的所有资源，待以后需要时再重新申请。这意味着进程已占有的资源会被暂时地释放，或者说是被抢占了，从而破坏了“不可抢占”条件。
3.6.3 破坏"等待循环"条件
一个能保证“循环等待”条件不成立的方法是，对系统所有资源类型进行线性排序，并赋予不同的序号。
3.7 避免死锁
避免死锁同样是属于事先预防的策略，但并不是事先采取某种限制措施，破坏产生死锁的必要条件，而是在资源动态分配过程中，防止系统进入不安全状态，以避免发生死锁。这种方法所施加的限制条件较弱，可能获得较好的系统性能，目前常用此方法来避免发生死锁。
3.7.1 系统安全状态
在死锁避免方法中，把系统的状态分为安全状态和不安全状态。当系统处于安全状态时，可避免发生死锁。反之，当系统处于不安全状态时，则可能进入到死锁状态。
- 安全状态
在该方法中，允许进程动态地申请资源，但系统在进行资源分配之前，应先计算此次资源分配的安全性。 - 安全状态举例
假定系统中有三个进程P1、P2和P3，共有12台磁带机。进程P1总共要求10台磁带机，P2和P3分别要求4台和9台。假设在T0时刻，进程P1、P2和P3已分别获得5台、2台和2台磁带机，尚有3台空闲未分配，如下表所示：
- 由安全状态向不安全状态的转换
如果不按照安全序列分配资源，则系统可能会由安全状态进入不安全状态。
3.7.2 利用银行家算法避免死锁
最有代表性的避免死锁的算法是Dijkstra的银行家算法。起这样的名字是由于该算法原本是为银行系统设计的，以确保银行在发放现金贷款时，不会发生不能满足所有客户需要的情况。在OS中也可用它来实现避免死锁。
1.银行家算法中的数据结构
为了实现银行家算法，在系统中必须设置这样四个数据结构，分别用来描述系统中可利用的资源、所有进程对资源的最大需求、系统中的资源分配，以及所有进程还需要多少资源的情况。
(1) 可利用资源向量Available。
(2) 最大需求矩阵Max。
(3) 分配矩阵Allocation。
(4) 需求矩阵Need。
2.银行家算法
设Requesti是进程Pi的请求向量，如果Request i[j]=K，表示进程Pi需要K个Rj类型的资源。当Pi发出资源请求后，系统按下述步骤进行检查：
(1) 如果Request i[j]≤Need[i, j]，便转向步骤(2)；否则认为出错，因为它所需要的资源数已超过它所宣布的最大值。
(2) 如果Request i[j]≤Available[j]，便转向步骤(3)； 否则，表示尚无足够资源，Pi须等待。
(3) 系统试探着把资源分配给进程Pi，并修改下面数据结构中的数值：Available[j] = Available[j] - Request i[j];Allocation[i, j] = Allocation[i, j] + Request i[j];Need[i, j] = Need[i, j] - Request i[j];
(4) 系统执行安全性算法，检查此次资源分配后系统是否处于安全状态。若安全，才正式将资源分配给进程Pi，以完成本次分配；否则，将本次的试探分配作废，恢复原来的资源分配状态，让进程Pi等待。
3.安全性算法
系统所执行的安全性算法可描述如下：
(1) 设置两个向量：① 工作向量Work，它表示系统可提供给进程继续运行所需的各类资源数目，它含有m个元素，在执行安全算法开始时，Work := Available；② Finish：它表示系统是否有足够的资源分配给进程，使之运行完成。开始时先做Finish[i] := false；当有足够资源分配给进程时，再令Finish[i] := true。
(2) 从进程集合中找到一个能满足下述条件的进程： ① Finish[i]=false;② Need[i, j]≤Work[j]; 若找到，执行步骤(3)，否则，执行步骤(4)。
(3) 当进程Pi获得资源后，可顺利执行，直至完成，并释放出分配给它的资源，故应执行：Work[j] = Work[j]+Allocation[i, j];
Finish[i] =true;
go to step 2;
(4) 如果所有进程的Finish[i]=true都满足，则表示系统处于安全状态；否则，系统处于不安全状态。
3.8 死锁的检测与解除
如果在系统中，既不采取死锁预防措施，也未配有死锁避免算法，系统很可能会发生死锁。在这种情况下，系统应当提供两个算法：① 死锁检测算法。该方法用于检测系统状态，以确定系统中是否发生了死锁。② 死锁解除算法。当认定系统中已发生了死锁，利用该算法可将系统从死锁状态中解脱出来。
3.8.1 死锁的检测
为了能对系统中是否已发生了死锁进行检测，在系统中必须：① 保存有关资源的请求和分配信息；② 提供一种算法，它利用这些信息来检测系统是否已进入死锁状态。
1.资源分配图(Resource Allocation Graph)
系统死锁，可利用资源分配图来描述。
该图是由一组结点N和一组边E所组成的一个对偶G = (N, E)，它具有下述形式的定义和限制：
(1) 把N分为两个互斥的子集，即一组进程结点P={P1, P2, …, Pn}和一组资源结点R={R1, R2, …, Rn}，N = P∪R。在图3-19所示的例子中，P = {P1, P2}，R = {R1, R2}，N = {R1, R2}∪{P1, P2}。
(2) 凡属于E中的一个边e∈E，都连接着P中的一个结点和R中的一个结点，e = {Pi, Rj}是资源请求边，由进程Pi指向资源Rj，它表示进程Pi请求一个单位的Rj资源。E = {Rj, Pi}是资源分配边，由资源Rj指向进程Pi，它表示把一个单位的资源Rj分配给进程Pi。图3-19中示出了两个请求边和两个分配边，即E = {(P1, R2), (R2, P2), (P2, R1), (R1, P1)}。
2.死锁定理
我们可以利用把资源分配图加以简化的方法(图3-19)，来检测当系统处于S状态时，是否为死锁状态。简化方法如下：
(1) 在资源分配图中，找出一个既不阻塞又非独立的进程结点Pi。在顺利的情况下，Pi可获得所需资源而继续运行，直至运行完毕，再释放其所占有的全部资源，这相当于消去Pi的请求边和分配边，使之成为孤立的结点。在图3-20(a)中，将P1的两个分配边和一个请求边消去，便形成图(b)所示的情况。
(2) P1释放资源后，便可使P2获得资源而继续运行，直至P2完成后又释放出它所占有的全部资源，形成图©所示的情况，即将P2的两条请求边和一条分配边消去。
(3) 在进行一系列的简化后，若能消去图中所有的边，使所有的进程结点都成为孤立结点，则称该图是可完全简化的；若不能通过任何过程使该图完全简化，则称该图是不可完全简化的。
3.死锁检测中的数据结构
死锁检测中的数据结构类似于银行家算法中的数据结构：
(1) 可利用资源向量Available，它表示了m类资源中每一类资源的可用数目。
(2) 把不占用资源的进程(向量Allocation=0)记入L表中，即Li∪L。
(3) 从进程集合中找到一个Requesti≤Work的进程，做如下处理：① 将其资源分配图简化，释放出资源，增加工作向量Work =Work + Allocation i。② 将它记入L表中。
(4) 若不能把所有进程都记入L表中，便表明系统状态S的资源分配图是不可完全简化的。因此，该系统状态将发生死锁。
3.8.2 死锁的解除
1.终止进程的方法
- 终止所有死锁进程
这是一种最简单的方法，即是终止所有的死锁进程，死锁自然也就解除了，但所付出的代价可能会很大。因为其中有些进程可能已经运行了很长时间，已接近结束，一旦被终止真可谓“功亏一篑”，以后还得从头再来。还可能会有其它方面的代价，在此不再一一列举。 - 逐个终止进程
稍微温和的方法是，按照某种顺序，逐个地终止进程，直至有足够的资源，以打破循环等待，把系统从死锁状态解脱出来为止。但该方法所付出的代价也可能很大。因为每终止一个进程，都需要用死锁检测算法确定系统死锁是否已经被解除，若未解除还需再终止另一个进程。另外，在采取逐个终止进程策略时，还涉及到应采用什么策略选择一个要终止的进程。选择策略最主要的依据是，为死锁解除所付出的“代价最小”。但怎么样才算是“代价最小”，很难有一个精确的度量。
2.付出代价最小的死锁接触算法
