操作系统_进程与线程(四)

目录

4. 死锁

4.1 死锁的概念

4.1.1 死锁的定义

4.1.2 死锁产生的原因

4.1.3 死锁的处理策略

4.2 死锁预防

4.3 死锁避免

4.3.1 系统安全状态

4.3.2 银行家算法

4.3.2.1 数据结构描述

4.3.2.2 银行家算法描述

4.3.2.3 安全性算法

4.3.3 安全性算法举例

4.3.4 银行家算法举例

4.4 死锁检测与解除

4.4.1 资源分配图

4.4.2 死锁定理

4.4.3 死锁解除

4.5 小结

---

4. 死锁

本节问题？

1. 为什么会产生死锁？产生死锁有什么条件？

2. 有什么办法可以解决死锁问题？

4.1 死锁的概念

4.1.1 死锁的定义

        在多道程序系统中，由于多个进程并发执行，改善了系统资源的利用率并提高了系统的处理能力。然而，多个进程的并发执行也带来了新的问题——死锁。所谓死锁，是指多个进程因竞争资源而造成的一种僵局（互相等待），若无外力作用，这些进程都将无法向前推进。

举个例子来看生活中的死锁现象：

        在一条河上有一座桥，桥面很窄，只能容纳一辆汽车通过。若有两辆汽车分别从桥的左右两端驶上该桥，则会出现下述冲突情况：此时，左边的汽车占有桥面左边的一段，要想过桥还需等待右边的汽车让出桥面右边的一段；右边的汽车占有桥面右边的一段，要想过桥还需等待左边的汽车让出桥面左边的一段。此时，若左右两边的汽车都只能向前行驶，则两辆汽车都无法过桥。

在计算机系统中也存在类似的情况：
        某计算机系统只有一台打印机和一台输入设备，进程  正占用输入设备，同时又提出使用打印机的请求，但此时打印机正被进程  所占用，而   在未释放打印机之前，又提出请求使用正被  占用的输入设备。这样，两个进程相互无休止地等待下去，均无法继续执行，此时两个进程陷入死锁状态。

        死锁就是：在并发环境中，各进程因竞争资源而造成的一种互相等待对方手里的资源，导致各进程都阻塞，都无法向前推进的现象，这就是 “死锁” 。发生死锁后若无外力干涉，这些进程都将无法向前推进。

4.1.2 死锁产生的原因

1. 系统资源的竞争

        通常系统中拥有的不可剥夺资源，其数量不足以满足多个进程运行的需要，使得进程在运行过程中，会因争夺资源而陷入僵局，如磁带机、打印机等。只有对不可剥夺资源的竞争才可能产生死锁，所可剥夺资源的竞争是不会引起死锁的。

2. 进程推进顺序非法

        进程在运行过程中，请求和释放资源的顺序不当，也同样会导致死锁。例如，并发进程 ， 分别保持了资源 ，，而进程  申请资源 、进程  申请资源  时，两者都会因为所需资源被占用而阻塞，于是导致死锁。         

        信号量使用不当也会造成死锁。进程间彼此相互等待对方发来的消息，也会使得这些进程间无法继续向前推进。例如，进程 A 等待进程 B 发的消息，进程 B 又在等待进程 A 发的消息，可以看出进程 A 和 B 不是因为竞争同一资源，而是在等待对方的资源导致死锁。

3. 死锁产生的必要条件

        产生死锁必须同时满足以下 4 个条件，只要其中任意一个条件不成立，死锁就不会发生。

        ① 互斥条件。进程要求对所分配的资源（如打印机）进程排他性使用，即在一段时间内某资源仅为一个进程所占有。此时若有其他进程请求该资源，则请求进程只能等待。只有对必须互斥使用的资源的争夺才会导致死锁。像内存、扬声器这样可以同时让多个进程使用的资源是不会导致死锁的。 

        ② 不剥夺条件。进程所获得的资源在未使用完之前，不能被其他进程强行夺走，即只能由获得该资源的进程自己来释放（只能是主动释放）。

        ③ 请求并保持条件。进程已经保持了至少一个资源，但又提出了新的资源请求，而该资源已被其他进程占有，此时请求进程被阻塞，但对自己已获得的资源保持不放。

        ④ 循环等待条件。存在一种进程资源的循环等待链，链中每个进程已获得的资源同时被链中下一个进程所请求。即存在一个处于等待态的进程集合 {，……}，其中  等待的资源被  （i = 0,1，……n-1）占用， 等待的资源被  占用。(注意：发生死锁时一定有循环等待，但是发生循环等待时未必死锁)

        直观上看，循环等待条件似乎和死锁的定义一样，其实不然。按死锁定义构成等待环所要求的条件更严，他要求  等待的资源必须由  来满足，而循环等待条件则无此限制。例如，系统中有两台输出设备， 占一台， 占有另一台，且 K 不属于集合 {0,1，……n}。 等待一台输出设备，它可从  获得，也可从  获得。因此，虽然 ， 和其他一些进程形成了循环等待圈，但  不在圈内，若  释放了输出设备，则可打破循环等待。

        如下图所示，因此循环等待只是死锁的必要条件。

        如果同类资源数大于 1 ，则即使有循环等待，也未必发生死锁。但如果系统中每类资源数都只有 1 个，那循环等待就是死锁的充分必要条件了。

        资源分配图含圈而系统又不一定有死锁的原因是：同类资源数大于 1 。但若系统中每类资源都只有一个资源，则资源分配图含圈就变成了系统出现死锁的充分必要条件。

区分不剥夺条件与请求并保持条件：

        举个例子：若你手上拿着一个苹果（即便你不打算吃），别人也不能把你手上的苹果拿走，这就是不剥夺条件；若你左手拿着一个苹果，允许你右手再去拿一个苹果，这就是请求并保持条件。

4.1.3 死锁的处理策略

        为使系统不发生死锁，必须设法破坏产生死锁的 4 个必要条件之一，或允许死锁产生，但当死锁发生时能检测出死锁，并有能力实现恢复。

•         1. 死锁预防。设置某些限制条件，破坏产生死锁的 4 个必要条件中的一个或几个。
•         2. 避免死锁。在资源的动态分配过程中，用某种方法防止系统进入不安全状态。
•         3. 死锁的检测及解除。无须采取任何限制性措施，允许进程在运行过程中发生死锁。通过系统的检测机构及时地检测出死锁的发生，然后采取某种措施解除死锁。

        预防死锁和避免死锁都属于事先预防策略；

        预防死锁的限制条件比较严格，实现起来较为简单，但往往导致系统的效率低，资源利用率低；

        避免死锁的限制条件相对宽松，资源分配后需要通过算法来判断是否进入不安全状态，实现起来较为复杂。

4.2 死锁预防

        防止死锁的发生只需破坏死锁产生的 4 个必要条件之一即可。

        1. 破坏互斥条件

        互斥是指必须互斥使用的资源的争夺才会导致死锁。若允许系统资源都能共享使用，则系统不会进入死锁状态。但有些资源根本不能同时访问，如打印机等临界资源只能互斥使用。所以，破坏互斥条件而预防死锁的方法不太可行，而且在有的场合应该保护这种互斥性。

        该策略的缺点：并不是所有的资源都可以改造成可共享使用的资源。并且为了系统安全，很多地方还必须保护这种互斥性。因此，很多时候都无法破坏互斥条件。

        2. 破坏不剥夺条件

        方案一：当一个已保持了某些不可剥夺资源的进程请求新的资源而得不到满足时，它必须释放已经保持的所有资源，待以后需要时再重新申请。这意味着，一个进程已占有的资源会被暂时释放，或者说是被剥夺，或从而破坏了不剥夺条件。也就是说，即使某些资源尚未使用完，也需要主动释放，从而破坏了不可剥夺条件。

        方案二：当某个进程需要的资源被其他进程所占有的时候，可以由操作系统协助，将想要的资源强行剥夺。这种方式一般需要考虑各进程的优先级（比如：剥夺调度方式，就是将处理机资源强行剥夺给优先级更高的进程使用）。

        该策略实现起来比较复杂，释放已获得的资源可能造成前一阶段工作的失效，反复地申请和释放资源会增加系统开销，降低系统吞吐量。这种方法常用于状态易于保存和恢复的资源，如 CPU 的寄存器及内存资源，一般不能用于打印机之类的资源。 

缺点：实现起来比较复杂。

           释放已获得的资源可能造成前一阶段工作的失效。因此这种方法一般只适用于易保存和恢复状态的资源，如 CPU 。

           反复地申请和释放资源会增加系统开销，降低系统吞吐量。

           若采用方案一，意味着只要暂时得不到某个资源，之前获得的那些资源就都需要放弃，以后再重新申请。如果一直发生这样的情况，就会导致进程饥饿。

        3. 破坏请求并保持条件

        采用预先静态分配方法，即进程在运行前一次申请完它所需要的全部资源，在它的资源未满足前，不把它投入运行。一旦投入运行，这些资源就一直归它所有，不再提出其他资源请求，这样就可以保证系统不会发生死锁。

        这种方法实现简单，但缺点也显而易见，系统资源被严重浪费，其中有些资源可能仅在运行初期或运行快结束时才使用，甚至根本不使用。而且还会导致 “饥饿” 现象，由于个别资源长期被其他进程占用时，将致使等待该资源的进程迟迟不能开始运行。  

        4. 破坏循环等待条件

        为了破坏循环等待条件，可采用顺序资源分配法。首先给系统中的资源编号，规定每个进程必须按编号递增的顺序请求资源，同类资源一次申请完。也就是说，只要进程提出申请分配资源  ，则该进程在以后的资源申请中就只能申请编号大于  的资源。

        这种方法存在的问题是：编号必须相对稳定，这就限制了新类型设备的增加；尽管在为资源编号时已考虑了大多数作业实际使用这些资源的顺序，但也经常会发生作业使用资源的顺序与系统规定顺序不同的情况，造成资源的浪费；此外，这种按规定次序申请资源的方法，也必然会给用户的编程带来麻烦。

4.3 死锁避免

        避免死锁同样属于事先预防策略，但并不是事先采取某种限制措施破坏死锁的必要条件，而是在资源动态分配过程中，防止系统进入不安全状态，以避免发生死锁。这种方法所施加的限制条件较弱，可以获得较好的系统性能。

4.3.1 系统安全状态

        避免死锁的方法中，允许进程动态地申请资源，但系统在进行资源分配之前，应先计算此次分配的安全性。若此次分配不会导致系统进入不安全状态，则允许分配；否则让进程等待。

        所谓安全状态，是指系统能按某种进程推进顺序（、……）为每个进程  分配其所需的资源，直至满足每个进程对资源的最大需求，使每个进程都可顺序完成。此时称 、…… 为安全序列。若系统无法找到一个安全序列，则称系统处于不安全状态。

        假设系统中有三个进程 、、，共有 12 台磁带机。进程  共需要 10 台磁带机， 和  分别需要 4 台和 9 台。假设在  时刻，进程 、、 已分别获得 5 台、2 台和 2 台，尚有 3 台未分配；见下表：

        在  时刻是安全的，因为存在一个安全序列  、 、；只要系统按此进程序列分配资源，那么每个进程都能顺利完成。也就是说，当前可用磁带机为 3 台，先把 3 台磁带机分配给  以满足其最大需求， 结束并归还资源后，系统由 5 台磁带机可用；接下来给  分配 5 台磁带机以满足其最大需求， 结束并归还资源后，剩余 10 台磁带机可用；最后分配 7 台磁带机给 ，这样  也能顺利完成。

        若在  时刻后，系统分配 1 台磁带机给  ，系统剩余可用资源数为 2 ，此时系统进入不安全状态，因为此时已无法再找到一个安全序列。当系统进入不安全状态后，便可能导致死锁。例如，把剩下的 2 台磁带机分配给  ，这样， 完成后只能释放 4 台磁带机，既不能满足  又不能满足 ，致使它们都无法推进到完成，彼此都在等待对方释放资源，陷入僵局，即导致死锁。

        并非所以的不安全状态都是死锁状态，但当系统进入不安全状态后，便可能进入死锁状态；反之，只要系统处于安全状态，系统便可避免进入死锁状态。

4.3.2 银行家算法

        银行家算法是最著名的死锁避免算法，其思想是：把操作系统视为银行家，操作系统管理的资源相当于银行家管理的资金，进程向操作系统请求分配资源相当于用户向银行家贷款。操作系统按照银行家制定的规则为进程分配资源。进程运行之前先声明对各种资源的最大需求量，当进程在执行中继续申请资源时，先测试该进程已占用的资源数与本次申请的资源数之和是否超过该进程声明的最大需求量。若超过则拒绝分配资源，若未超过则再测试系统现存的资源能否满足该进程尚需的最大资源量，若能满足则按当前的申请量分配资源，否则也要推迟分配。

4.3.2.1 数据结构描述

        可用资源向量 Available：含有 m 个元素的数组，其中每个元素代表一类可用的资源数目。Available[ j ] = K 表示系统中现有  类资源 K 个。

        最大需求矩阵 Max：n * m 矩阵，定义系统中 n 个进程中的每个进程对 m 类资源的最大需求。简单来说，一行代表一个进程，一列代表一类资源。Max[ i，j ] = K 表示进程 i 需要  类资源的最大数目为 K。

        分配矩阵 Allocation：n * m 矩阵，定义系统中每类资源当前已分配给每个进程的资源数。Allocation[ i，j ] = K 表示进程 i 当前已分得  类资源的数目为 K 。

        需求矩阵 Need：n * m 矩阵，表示每个进程接下来最多还需要多少资源。Need[ i，j ] = K 表示进程 i 接下来还需要  类资源的数目为 K 。

        上述三个矩阵间存在下述关系：

Need = Max - Allocation

4.3.2.2 银行家算法描述

        设  是进程  的请求向量，[ j ] = K 表示进程  需要 j 类资源 K 个。当  发出资源请求后，系统按下述步骤进行检查：

        ① 若 [ j ]  Need[ i，j ] ，则转向步骤 ②；否则认为出错，因为它所需要的资源数已超过它所宣布的最大值。

        ② 若 [ j ]  Available[ j ]，则转向步骤 ③；否则，表示尚无足够资源， 须等待。

        ③ 系统试探着把资源分配给进程 ，并修改下面数据结构中的数值：

Available = Available - Request；

Allocation[ i，j ] = Allocation[ i，j ] + [ j ]；

Need[ i，j ] = Need[ i，j ] - [ j ]；

        ④ 系统执行安全性算法，检查此次资源分配后，系统是否处于安全状态。若安全，才正式将资源分配给进程  ，以完成本次分配；否则，将本次的试探分配作废，恢复原来的资源分配状态，让进程  等待。

4.3.2.3 安全性算法

        设置工作向量 Work，有 m 个元素，表示系统中的剩余可用资源数目。在执行安全性算法开始时，Work = Available。

        ① 初始时安全序列为空。

        ② 从 Need 矩阵中找出符合下面条件的行：该行对应的进程不在安全序列中，而且该行小于等于 Work 向量，找到后，把对应的进程加入安全序列；若找不到，则执行步骤 ④。

        ③ 进程  进入安全序列后，可顺利执行，直至完成，并释放分配给它的资源，因此应执行 Work = Work + Allocation[ i ]，其中 Allocation[ i ] 表示进程  代表的在 Allocation 矩阵中对应的行，返回步骤 ② 。

        ④ 若此时安全序列中已有所有进程，则系统处于安全状态，否则系统处于不安全状态。

4.3.3 安全性算法举例

通过一个具体的例子来看上面介绍的安全性算法：

        假定系统中有 5 个进程 {，，，，} 和三类资源 { A,B,C }，各种资源的数量分别为 10，5，7，在  时刻的资源分配情况如下表所示：

         时刻的安全性。利用安全性算法对  时刻的资源分配进行分析。

        ① 从题目中我们可以提取 Max 矩阵和 Allocation 矩阵，这两个矩阵相减可得到 Need 矩阵：

        ② 将 Work 向量与 Need 矩阵的各行进行比较，找出比 Work 矩阵小的行。（Work 向量初始时就等于 Available）

        ③ 释放  所占资源，即把  进程对应的 Allocation 矩阵中的一行与 Work 向量相加：

        此时的需求矩阵更新为（去掉了  对应的一行）：

        再用更新的 Work 向量和 Need 矩阵重复步骤 ② 。利用安全性算法分析  时刻的资源分配情况如下表所示，最后得到一个安全序列 {，，，，}。

4.3.4 银行家算法举例

        安全性算法是银行家算法的核心，在银行家算法的题目中，一般会有某个进程的一个资源请求向量，读者只要执行上面所介绍的银行家算法的前三步，马上就会得到更新的 Allocation 矩阵和 Need 矩阵，再按照上例的安全性算法判断，就能知道系统能否满足进程提出的资源请求。

        假设系统中资源的分配和剩余情况如下表所示：

        ①  请求资源： 发出请求向量(1, 0,2),系统按银行家算法进行检查：

        (1, 0,2)  (1,2,2)

        (1, 0,2)  (3,3,2)

        系统先假定可为  分配资源，并修改

        Available = Available 一 = (2, 3, 0)

         = + = (3, 0, 2)

         = - = (0, 2, 0)

        由此形成的资源变化情况如上表中的圆括号所示。

        令Work = Available = (2,3,0),再利用安全性算法检查此时系统是否安全，如下表所示。

        由所进行的安全性检查得知，可找到一个安全序列 {，，，，}。因此，系统是安全的，可以立即将  所申请的资源分配给它。分配后的系统中的资源情况如下表所示：

        ②  请求资源：  发出请求向量 (3,3,0)，系统按银行家算法进行检查：

        (3,3,0)  (4,3,1)

        (3,3,0) > Available(2,3,0)，让  等待。

        ③  请求资源： 发出请求向量 (0,2,0)，系统按银行家算法进行检查：

        (0,2,0)  (7,4,3)

        (0,2,0) > Available(2,3,0)

        系统暂时先假定可为  分配资源，并修改有关数据：

        Available = Available -  = (2,1,0)

         =  +  = (0,3,0)

         =  -  = (7,2,3)，结果如下所示：

        进行安全性检查：可用资源 Available(2,1,0) 已不能满足任何进程的需要，因此系统进入不安全状态，因此拒绝  的请求，让  等待，并将 Available，， 恢复为之前的值。

4.4 死锁检测与解除

        前面介绍了一些处理措施，若系统为进程分配资源时不采用任何措施，则应该提供死锁检测和解除的手段。

4.4.1 资源分配图

        系统死锁可利用资源分配图来描述。

        用圆圈代表一个进程，用框代表一类资源。由于一种类型的资源可能有多个，因此用框中的一个圆代表一类资源中的一个资源。从进程到资源的有向边称为请求边，表示该进程申请一个单位的该类资源；从资源到进程的边称为分配边，表示该类资源已有一个资源分配到了该进程。

        如上资源分配图所示：进程  已经分得了两个  资源，并又请求了一个  资源；进程  分得了一个  资源和一个  资源，并又请求一个  资源。

4.4.2 死锁定理

        简化资源分配图可检测系统状态 S 是否为死锁状态。

        1. 在资源分配图中，找出既不阻塞又不孤点的进程 , (即找出一条有向边与它相连，且该有向边对应资源的申请数量小于等于系统中已有的空闲资源数量，如在图2.15中， 没有空闲资源， 有一个空闲资源。若所有连接该进程的边均满足上述条件，则这个进程能继续运行直至完成，然后释放它所占有的所有资源)。消去它所有的请求边和分配边，使之成为孤立的结点。在图2.16(a)中， 是满足这一条件的进程结点，将  的所有边消去，便得到图2.16(b)所示的情况。

        这里要注意一个问题，判断某种资源是否有空闲，应该用它的资源数量减去它在资源分配图中的出度，例如在图2.15中， 的资源数为3，而出度也为3，所以  没有空闲资源， 的资源数为2，出度为1，所以  有一个空闲资源。

         2. 进程  所释放的资源，可以唤醒某些因等待这些资源而阻塞的进程，原来的阻塞进程可能变为非阻塞进程。在图2.15中，进程  就满足这样的条件。根据 1. 中的方法进行一系列简化后，若能消去图中所有的边，则称该图是可完全简化的，如图2.16（c）所示。

        S 为死锁的条件是当且仅当 S 状态的资源分配图是不可完全简化的，该条件称为死锁定理。

4.4.3 死锁解除

        一旦检测出死锁，就应立即采取相应的措施来解除死锁。

        1. 资源剥夺法。挂起某些死锁进程，并抢占它的资源，将这些资源分配给其他的死锁进程。但应防止被挂起的进程长时间得不到资源而处于资源匮乏的状态。

        2. 撤销进程法。强制撤销部分甚至全部死锁进程并剥夺这些进程的资源。撤销的原则可以按进程优先级和撤销进程代价的高低进行。

        3. 进程回退法。让一 (或多) 个进程回退到足以回避死锁的地步。进程回退时自愿释放资源而非被剥夺。要求系统保持进程的历史信息，设置还原点。

4.5 小结

1. 为什么会产生死锁？产生死锁有什么条件？

        由于系统中存在一些不可剥夺资源，当两个或两个以上的进程占有自身的资源并请求对方的资源时，会导致每个进程都无法向前推进，这就是死锁。死锁产生的必要条件有4个，分别是互斥条件、不剥夺条件、请求并保持条件和循环等待条件。

        互斥条件是指进程要求分配的资源是排他性的，即最多只能同时供一个进程使用。

        不剥夺条件是指进程在使用完资源之前，资源不能被强制夺走。

        请求并保持条件是指进程占有自身本来拥有的资源并要求其他资源。

        循环等待条件是指存在一种进程资源的循环等待链。

2. 有什么办法可以解决死锁问题？

        死锁的处理策略可以分为预防死锁、避免死锁及死锁的检测与解除。

        死锁预防是指通过设立一些限制条件，破坏死锁的一些必要条件，让死锁无法发生。

        死锁避免指在动态分配资源的过程中，用一些算法防止系统进入不安全状态，从而避免死锁。

        死锁的检测和解除是指在死锁产生前不采取任何措施，只检测当前系统有没有发生死锁，若有，则采取一些措施解除死锁。