死锁预防与死锁避免

死锁预防

防止死锁的发生只需破坏死锁产生的四个必要条件之一即可。
1) 破坏互斥条件
如果允许系统资源都能共享使用,则系统不会进入死锁状态。但有些资源根本不能同时访问,如打印机等临界资源只能互斥使用。所以,破坏互斥条件而预防死锁的方法不太可行,而且在有的场合应该保护这种互斥性。
2) 破坏不剥夺条件
当一个已保持了某些不可剥夺资源的进程,请求新的资源而得不到满足时,它必须释放已经保持的所有资源,待以后需要时再重新申请。这意味着,一个进程已占有的资源会被暂时释放,或者说是被剥夺了,或从而破坏了不可剥夺条件。

该策略实现起来比较复杂,释放已获得的资源可能造成前一阶段工作的失效,反复地申请和释放资源会增加系统开销,降低系统吞吐量。这种方法常用于状态易于保存和恢复的资源,如CPU的寄存器及内存资源,一般不能用于打印机之类的资源。
3) 破坏请求和保持条件
釆用预先静态分配方法,即进程在运行前一次申请完它所需要的全部资源,在它的资源未满足前,不把它投入运行。一旦投入运行后,这些资源就一直归它所有,也不再提出其他资源请求,这样就可以保证系统不会发生死锁。

这种方式实现简单,但缺点也显而易见,系统资源被严重浪费,其中有些资源可能仅在运行初期或运行快结束时才使用,甚至根本不使用。而且还会导致“饥饿”现象,当由于个别资源长期被其他进程占用时,将致使等待该资源的进程迟迟不能开始运行。
4) 破坏循环等待条件
为了破坏循环等待条件,可釆用顺序资源分配法。首先给系统中的资源编号,规定每个进程,必须按编号递增的顺序请求资源,同类资源一次申请完。也就是说,只要进程提出申请分配资源Ri,则该进程在以后的资源申请中,只能申请编号大于Ri的资源。

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

死锁避免

避免死锁同样是属于事先预防的策略,但并不是事先釆取某种限制措施破坏死锁的必要条件,而是在资源动态分配过程中,防止系统进入不安全状态,以避免发生死锁。这种方法所施加的限制条件较弱,可以获得较好的系统性能。
1. 系统安全状态
避免死锁的方法中,允许进程动态地申请资源,但系统在进行资源分配之前,应先计算此次资源分配的安全性。若此次分配不会导致系统进入不安全状态,则将资源分配给进程; 否则,让进程等待。

所谓安全状态,是指系统能按某种进程推进顺序( P1, P2, ..., Pn),为每个进程Pi分配其所需资源,直至满足每个进程对资源的最大需求,使每个进程都可顺序地完成。此时称 P1, P2, ..., Pn 为安全序列。如果系统无法找到一个安全序列,则称系统处于不安全状态。

假设系统中有三个进程P1、P2和P3,共有12 台磁带机。进程P1总共需要10台磁带机,P2和P3 分别需要4台和9台。假设在T0时刻,进程P1、P2 和P3已分别获得5合、2台和2台,尚有3台未分配,见表2-15。

表2-15 资源分配
进程 最大需求 已分配 可用
P11053
P242 
P392 

则在T0时刻是安全的,因为存在一个安全序列P2、Pl、P3,即只要系统按此进程序列分配资源,则每个进程都能顺利完成。若在T0时刻后,系统分配1台磁带机给P3,则此时系统便进入不安全状态,因为此时已无法再找到一个安全序列。

并非所有的不安全状态都是死锁状态,但当系统进入不安全状态后,便可能进入死锁状态;反之,只要系统处于安全状态,系统便可以避免进入死锁状态。
2. 银行家算法
银行家算法是最著名的死锁避免算法。它提出的思想是:把操作系统看做是银行家,操作系统管理的资源相当于银行家管理的资金,进程向操作系统请求分配资源相当于用户向银行家贷款。操作系统按照银行家制定的规则为进程分配资源,当进程首次申请资源时,要测试该进程对资源的最大需求量,如果系统现存的资源可以满足它的最大需求量则按当前的申请量分配资源,否则就推迟分配。当进程在执行中继续申请资源时,先测试该进程已占用的资源数与本次申请的资源数之和是否超过了该进程对资源的最大需求量。若超过则拒绝分配资源,若没有超过则再测试系统现存的资源能否满足该进程尚需的最大资源量,若能满足则按当前的申请量分配资源,否则也要推迟分配。

1) 数据结构描述
可利用资源矢量Available:含有m个元素的歎组,其中的每一个元素代表一类可用的资源数目。Available[j]=K,则表示系统中现有Rj类资源K个。

最大需求矩阵Max:为n*m矩阵,定义了系统中n个进程中的每一个进程对m类资源的最大需求。Max[i, j]=K,则表示进程i需要Rj类资源的最大数目为K。

分配矩阵Allocation:为n*m矩阵,定义了系统中每一类资源当前已分配给每一进程的资源数。All0Cati0n[i, j]= K,则表示进程i当前已分得Rj类资源的数目为K。

需求矩阵Need:为n*m矩阵,表示每个进程尚需的各类资源数。Need[i, j]=K,则表示进程i还需要Rj类资源的数目为K。

上述三个矩阵间存在下述关系:
Need[i, j] = Max[i, j] - Allocation[i, j]

2) 银行家算法描述
设Requesti是进程Pi的请求矢量,如果Requesti[j]K,表示进程Pi需要Rj类资源K个。当Pi发出资源请求后,系统按下述步骤进行检查:

①如果Requesti[j] <= Need[i, j],便转向步骤②;否则认为出错,因为它所需要的资源数已超过它所宣布的最大值。

②如果Requesti[j] <= Available[j],便转向步骤③;否则,表示尚无足够资源,Pi须等待。

③系统试探着把资源分配给进程Pi,并修改下面数据结构中的数值:
   
   
  1. Available[j] = Available[j] - Requesti[j];
  2. Allocation[i, j] = Allocation[i, j] + Requesti[ j];
  3. Need[i, j] = Need[i, j] - Requesti[j];

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

3) 安全性算法
①设置两个矢量。工作矢量Work;它表示系统可提供给进程继续运行所需的各类资源数目,它含有所个元素,在执行安全算法开始时,Work=Available; Finish:它表示系统是否有足够的资源分配给进程,使之运行完成。开始时 Finish[i]=false;当有足够资源分配给进程 Pi 时,再令 Finish[i]=true。

②从进程集合中找到一个能满足下述条件的进程:Finish[i]=false;    Need[i, j]<=Work[j]; 若找到,执行下一步骤,否则,执行步骤4。

③当进程Pi获得资源后,可顺利执行,直至完成,并释放出分配给它的资源,故应执行:
   
   
  1. Work[j]=Work[j]+Allocation[i, j];
  2. Finish[i]=true;
  3. go to step <2>;

④如果所有进程的Finish[i]=tme都满足,则表示系统处于安全状态;否则,系统处于不安全状态。
3. 银行家算法举例
假定系统中有5个进程{P0, P1, P2, P3, P4}和三类资源{A, B, C},各种资源的数量分别为10、5、7,在T0时刻的资源分配情况见表2-16。

1) T0时刻的安全性。
利用安全性算法对T0时刻的资源分配进行分析,由表2-17可知,在T0时刻存在着一个安全序列{P1, P3, P4, P2, P0},故系统是安全的。

表2-16 T0时刻的资源分配
进程 / 资源情况 Max
A  B  C
Allocation
A  B  C
Need
A  B  C
Available
A  B  C
P07  5  30  1  07  4  33  3  2
(2  3  0)
P13  2  22  0  0
(3  0  2)
1  2  2
(0  2  0)
 
P29  0  23  0  26  0  0 
P32  2  22  1  10  1  1 
P44  3  30  0  24  3  1 

表2-17 T0时刻的安全序列
进程 / 资源情况 Work
A  B  C
Need
A  B  C
Allocation
A  B  C
Work+Allocation
A  B  C
Finish
P13  3  21  2  22  0  05  3  2true
P35  3  20  1  12  1  17  4  3true
P47  4  34  3  10  0  27  4  5true
P27  4  56  0  03  0  210  4  7true
P010  4  77  4  30  1  010  5  7true

2) P1请求资源
P1发出请求矢量Request1(l,, 0, 2),系统按银行家算法进行检查:
  • Request1(1, 0, 2) <= Need1(l, 2, 2)。
  • Request1(1, 0, 2) <= Available1(3, 3, 2)。
  • 系统先假定可为P1分配资源,并修改Available、Allocation1和Need1矢量,由此形成的资源变化情况见表2-18。
  • 再利用安全性算法检查此时系统是否安全。

表2-18 P1申请资源时的安全性检测
进程 / 资源情况 Work
A  B  C
Need
A  B  C
Allocation
A  B  C
Work+ Allocation
A  B  C
Finish
P12  3  00  2  03  0  25  3  2true
P35  3  20  1  12  1  17  4  3true
P47  4  34  3  10  0  27  4  5true
P07  4  57  4  30  1  07  5  5true
P27  5  56  0  03  0  210  5  7true

3) P4请求资源
P4发出请求矢量Request4(3, 3, 0),系统按银行家算法进行检查:
  • Request4(3, 3, 0) <= Need4(4, 3, 1)。
  • Request4(3, 3, 0) > Available(2, 3, 0),让 P4 等待。

4) P0请求资源
P0发出请求矢量Request0(0, 2, 0),系统按银行家算法进行检查:
  • Request0(0, 2, 0) <= Need0(7, 4, 3)。
  • Request0(0, 2, 0) <= Available(2, 3, 0)。
  • 系统暂时先假定可为P0分配资源,并修改有关数据,见表2-19。

表2-19 为P0分配资源后的有关资源数据
进程 / 资源情况 Allocation
A  B  C
Need
A  B  C
Available
A  B  C
P00  3  07  2  32  1  0
P13  0  20  2  0 
P23  0  26  0  0 
P32  1  10  1  1 
P40  0  24  3  1 

5) 进行安全性检测。
可用资源Available(2, 1, 0)已不能满足任何进程的需要,故系统进入不安全状态,此时系统不分配资源
  • 0
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值