操作系统第三章第节

预防死锁的方法

预防死锁

资源的排他性无法更改,故在其他3个条件上入手

(1)     摒弃“请求和保持”条件:所有进程开始运行前,必须一次性的申请其在整个运行过程所需的全部资源(AND)。算法简单、易于实现且很安全。但缺点是资源浪费严重、或进程延迟运行。

(2)     摒弃“不剥夺”条件:允许进程先运行,但当提出的新要求不被满足时必须释放它已保持的所有资源,待以后需要时再重新申请。实现比较复杂且付出很大代价。可能会造成前功尽弃,反复申请和释放等情况。

(3)     摒弃“环路等待”条件

((1))有序设置资源:将所有资源按类型进行线性排队,赋予不同序号。所有进程对资源的请求必须严格按照资源序号递增的次序提出,这样在所形成的资源分配图中,不可能会出现环路。

((2))与前两种策略比较,资源利用率和系统吞吐量都有较明显的改善。但也存在严重问题:

资源编号限制新设备的增加;

应用中的使用设备顺序与规定的顺序并不协调;

限制了用户编程自由。

2.    
避免死锁

名词:

v  
安全状态:系统能按某种进程顺序为每个进程分配所需资源,直至满足每个进程对资源的最大需求,并能顺利完成。

v  
不安全状态:系统无法找到一种使多个进程能够顺利分配资源执行完的安全序列。

v  
每次资源分配时,都应分析判断资源分配图,看该次操作后是否有安全序列。若没有,说明该操作会使系统进入不安全状态。

v   只要使系统始终处于安全状态,便可避免发生死锁。

v   不是所有的不安全状态都是死锁状态。

  1. 银行家算法避免死锁

v           最有代表性的避免死锁的算法,是Dijkstra的银行家算法。由于该算法能用于银行系统现金贷款的发放而得名。

v           【思路描述】:随时对系统中的所有资源信息进行统计,包括每种资源的数量、已分配给各进程的数量;每当进程提出某种资源请求时判断该请求分配后是否安全,如果安全才分配。对每个资源请求的处理都要保证系统始终从一个安全状态到另一个安全状态。

(1)银行家算法中的数据结构

((1))各类可利用资源的数量

u  向量Available :(i1,i2,…,im),含m个元素,每个元素代表一类可利用的资源数目。

u  动态变化的,初始值是系统配置的该类资源的全部数目,值随资源的分配与回收而动态的改变。

u  实现:一维数组。Available【j】=K,表示系统中Rj类资源现有可用数量为K个。

((2))每个进程对每类资源的需求

最大需求、已获得的、还需要的

(((1)))最大需求矩阵Max

v  n*m,系统中n个进程中每个进程分别对m类资源的最大需求。

v  取值:根据进程需求赋初始值。

v  实现:二维数组。Max【i,j】=K,表示进程 i 需要Rj类资源的最大数目为K。

(((2)))已分配矩阵Allocation。

u  n*m,定义系统中每一进程已获得的每类资源数量。

u  Allocation【i,j】=K,表示进程i当前已分得Rj类资源数为K。

(((3)))还需求的矩阵Need。

u  n*m,表示每一进程尚需的各类资源数。

u  Need【i,j】=K,表示进程i还需要Rj类资源K个,方能完成任务。

|  上述三个矩阵存在关系:

Max【i,j】= Allocation【i,j】+Need【i,j】

|  每次,给进程 i 分配资源的动作,影响上述数据结构的取值:

Available【 µ 】,Allocation【i,µ】,Need【i,µ】

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值