死锁
死锁
什么是死锁?
在两个或者多个并发进程中,如果每个进程持有某种资源而又等待其它进程释放它或它们现在保持着的资源,在未改变这种状态之前都不能向前推进,称这一组进程产生了死锁。通俗的讲就是两个或多个进程无限期的阻塞、相互等待的一种状态。
死锁产生的四个必要条件
- 互斥条件: 一个资源一次只能被一个进程使用;
- 请求与保持条件:一个进程因请求资源而阻塞时,对已获得资源保持不放;
- 不剥夺条件: 进程获得的资源,在未完全使用完之前,不能强行剥夺;
- 循环等待条件: 若干进程之间形成一种头尾相接的环形等待资源关系。
解决死锁的思路
- 预防死锁: 通过破坏死锁四个必要条件之一,来防止死锁产生;
- 避免死锁: 在资源的动态分配过程中,用某种方法防止系统进入不安全状态,从而避免发生死锁;
- 检测死锁: 允许进程在运行过程中发生死锁,但是可以通过检测机构及时检测出死锁,然后通过合适的措施,把进程从死锁过程中解脱出来;
- 解除死锁: 当检测系统中已经发生死锁时,就采用相应措施,将进程从死锁状态中解脱出来。
- 忽略死锁: 比如:鸵鸟算法,当系统发生死锁时不会对用户造成多大影响,或系统很少发生死锁的场合。
静态策略:预防死锁
破坏“互斥”条件
如果把只能互斥使用的资源改造为允许共享使用,则系统不会进入死锁状态。
比如:SPOOLing技术。操作系统可以采用SPOOLing 技术把独占设备在逻辑上改造成共享设备。
缺点:并不是所有的资源都可以改造成可共享使用的资源。并且为了系统安全,很多地方还必须保护这种互斥性。因此,很多时候都无法破坏互斥条件。
破坏“请求和保持”条件
我们必须保证:当一个进程在请求资源时,它不能持有不可抢占的系统资源。在此,有两种协议可供选择。
第一种协议: 该协议规定,所有进程在开始运行之前,必须一次性地申请其在整个运行过程中所需的全部资源。此时若系统有足够的资源分配给某进程,便可把其需要的所有资源分配给它,这样,该进程在整个运行期间,便不会再提出资源要求,从而破坏了“请求”条件。系统在分配资源时,只要有一种资源不能满足进程的要求,即使其它所需的各资源都空闲也不分配给该进程;
第一种协议虽然简单易行且安全,但是它导致资源被严重浪费,严重的降低了资源的利用率;进程会经常发生饥饿现象。 因此比较推荐第二种协议。
第二种协议: 该协议是对第一种协议的改进,它允许一个进程只获得运行初期所需的资源后,便开始运行。进程运行过程中再逐步释放已分配给自己的、且已用毕的全部资源,然后再请求新的所需资源。
破坏“不剥夺”条件
方案一:当某个进程请求新的资源得不到满足时,便立即释放保持的所有资源,待以后需要时再重新申请。也就是说,即使某些资源尚未使用完,也需要主动释放,从而破坏了不可剥夺条件。
方案二:当某个进程需要的资源被其他进程所占有的时候,可以由操作系统协助,将想要的资源强行剥夺。这种方式一般需要考虑各进程的优先级。比如剥夺调度方式,就是将处理机资源强行剥夺给优先级更高的进程使用。
缺点:
- 实现起来比较复杂。
- 释放已获得的资源可能造成前一阶段工作的失效。因此这种方法一般只适用于易保存和恢复状态的资源,如CPU。
- 反复地申请和释放资源会增加系统开销,降低系统吞吐量。
- 若采用方案一,意味着只要暂时得不到某个资源,之前获得的那些资源就都需要放弃,以后再重新申请。如果一直发生这样的情况,就会导致进程饥饿。
破坏“循环等待”条件
顺序资源分配法: 首先给系统中的资源编号,规定每个进程必须按编号递增的顺序请求资源,同类资源(即编号相同的资源)一次性申请完。
原理: 一个进程只有已占有小编号的资源时,才有资格申请更大编号的资源。按此规则,已持有大编号资源的进程不可能逆向地回来申请小编号的资源,从而就不会产生循环等待的现象,进而预防死锁的发生。
缺点:
- 不方便增加新的设备,因为可能需要重新分配所有的编号;
- 进程实际使用资源的顺序可能和编号递增顺序不一致,会导致资源浪费;
- 必须按规定次序申请资源,用户编程麻烦。
动态策略:避免死锁
安全序列
所谓安全序列,就是指如果系统按照这种序列分配资源,则每个进程都能顺利完成。只要能找出一个安全序列,系统就是安全状态。当然,安全序列可能有多个。
如果分配了资源之后,系统中找不出任何一个安全序列,系统就进入了不安全状态。这就意味着之后可能所有进程都无法顺利的执行下去。
当然,如果有进程提前归还了一些资源,那系统也有可能重新回到安全状态,不过我们在分配资源之前总是要考虑到最坏的情况。
系统的不安全状态与死锁的联系
如果系统处于安全状态,就一定不会发生死锁。
如果系统进入不安全状态,就可能发生死锁。
处于不安全状态未必就是发生了死锁,但发生死锁时一定是在不安全状态。
因此可以在资源分配之前预先判断这次分配是否会导致系统进入不安全状态,以此决定是否答应资源分配请求。
这也是“银行家算法”的核心思想。
银行家算法
核心思想:在进程提出资源申请时,先预判此次分配是否会导致系统进入不安全状态。如果会进入不安全状态,就暂时不答应这次请求,让该进程先阻塞等待。
举例,系统中有5个进程P0-P4,3种资源R0~R2,初始数量为(10,5,7),则某一时刻的情况可表示如下:
银行家算法的代码实现:
假设系统中有n个进程,m种资源。
每个进程在运行前先声明对各种资源的最大需求数,则可用一个n*m的矩阵(可用二维数组实现)表示所有进程对各种资源的最大需求数。不妨称为最大需求矩阵Max,Max[i, j]=K表示进程Pi最多需要K个资源Rj。
同理,系统可以用一个n*m的分配矩阵Allocation表示对所有进程的资源分配情况。
由此得到Max - Allocation = Need矩阵,表示各进程最多还需要多少各类资源。
另外,还要用一个长度为m的一维数组Available表示当前系统中还有多少可用资源。
某进程Pi向系统申请资源,可用一个长度为m的一维数组Request表示本次申请的各种资源量。
可用银行家算法预判本次分配是否会导致系统进入不安全状态:
- 如果 R e q u e s t [ i ] ≤ N e e d [ i , j ] ( 0 ≤ j ≤ m ) R e q u e s t [ i ] ≤ N e e d [ i , j ] ( 0 ≤ j ≤ m ) Request[i]≤Need[i,j](0≤j≤m) 便转向2,否则认为出错。
- 如果 R e q u e s t [ i ] ≤ A v a i l a b l e [ i ] ( 0 ≤ j ≤ m ) R e q u e s t [ i ] ≤ A v a i l a b l e [ i ] ( 0 ≤ j ≤ m ) Request[i]≤Available[i](0≤j≤m),便转向3,否则表示尚无足够资源,Pi必须等待。
- 系统试探着把资源分配给进程Pi,并修改相应的数据(并非真的分配,修改数值只是为了做预判)。
- 操作系统执行安全性算法,检查此次资源分配后,系统是否处于安全状态。若安全,才正式分配;否则,恢复相应数据,让进程阻塞等待。
安全性算法步骤:
- 检查当前的剩余可用资源是否能满足某个进程的最大需求,
- 如果可以,就把该进程加入安全序列,并把该进程持有的资源全部回收。
- 不断重复上述过程,看最终是否能让所有进程都加入安全序列。
死锁的检测与解除
预防死锁和避免死锁,都是不允许死锁的发生。而死锁的检测与解除允许死锁的发生,然后发现并解决死锁。
资源分配图
两种结点:
-
进程结点:对应一个进程。
-
资源结点:对应一类资源,一类资源可能有多个。
两种边:
- 进程结点→资源结点:表示进程想申请几个资源(每条边代表一个)
- 资源节点→程结点:表示已经为进程分配了几个资源(每条边代表一个)
死锁的检测
为了能对系统是否已发生了死锁进行检测,必须:
- 用某种数据结构(资源分配图)来保存资源的请求和分配信息。
- 提供一种算法,利用上述信息来检测系统是否已进入死锁状态。
死锁检测算法:
- 在资源分配图中,找出既不阻塞又非独立的进程结点Pi,在顺利的情况下,Pi可以得到所需的资源而继续运行,直至完成,然后释放它所占有的所有资源。这相当于消去它所有的请求边和分配边,使之称为孤立的结点。
- 进程Pi所释放的资源,可以唤醒某些因等待这些资源而阻塞的进程,原来的阻塞进程可能变为非阻塞进程。然后重复上面的过程,消去请求边和分配边。
- 若能消去图中所有的边,使得图中的进程结点变为孤立点,则称该图是可完全简化的,否则称该图是不可完全简化的。
如果某时刻系统的资源分配图是不可完全简化的,那么此时系统死锁。
举例:
P1既不阻塞又不是孤点,消去它所有的请求边和分配边,使之称为孤立的结点。然后唤醒被阻塞的P2,消去它所有的请求边和分配边,该图是可完全简化的。
死锁的解除
主要有3中方法:
- 资源剥夺法:挂起(暂时放到外存上)某些死锁进程,并抢占它的资源,将这些资源分配给其他的死锁进程。但是应防止被挂起的进程长时间得不到资源而饥饿。
- 撤销进程法(或称终止进程法):强制撤销部分、甚至全部死锁进程,并剥夺这些进程的资源。这种方式的优点是实现简单,但所付出的代价可能会很大。因为有些进程可能已经运行了很长时间,已经接近结束了,一旦被终止可谓功亏一篑,以后还得从头再来。
- 进程回退法:让一个或多个死锁进程回退到足以避免死锁的地步。这就要求系统要记录进程的历史信息,设置还原点。
解决死锁的优先级:
- 进程优先级
- 已执行多长时间
- 还要多久能完成
- 进程已经使用了多少资源
- 进程是交互式的还是批处理式的