操作系统死锁

产生死锁的原因:
1、竞争资源。系统中供多个进程共享的资源如打印机、公用队列等的数目不满足需要时,会引起资源竞争而产生死锁。
2、进程间推进顺序非法。进程在运行过程中,请求和释放资源的顺序不当,同样会导致死锁。

产生死锁的必要条件:
互斥条件:进程对所分配到的资源进行排他性使用
请求和保持条件:进程已经保持了至少一个资源,又提出新的资源请求,而新请求资源被其他进程占有只能造成自身进程阻塞,但对自己已获得的其他资源保持不放,必然影响其他进程。
不剥夺条件:进程已获得的资源未使用完之前不能被剥夺,只能在使用完时由自己释放。
环路等待条件

预防死锁的方法:
摒弃“请求和保持”条件;摒弃“不剥夺”条件;摒弃“环路等待”条件

安全状态:
系统能按某种进程顺序为每个进程分配所需资源,直至满足每个进程对资源的最大需求,并能顺利完成。只要使系统始终处于安全状态,便可避免发生死锁。但不是所有的不安全状态都是死锁状态。

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

各类可利用资源的数量:一维数组。Available【j】=K,表示系统中Rj类资源现有可用数量为K个。
最大需求矩阵Max:二维数组。Max【i,j】=K,表示进程 i 需要Rj类资源的最大数目为K。
已分配矩阵Allocation:Allocation【i,j】=K,表示进程i当前已分得Rj类资源数为K。
还需求的矩阵Need:Need【i,j】=K,表示进程i还需要Rj类资源K个,方能完成任务。
Max【i,j】= Allocation【i,j】+Need【i,j】

(1)IF Requesti[j]<= Need[i,j] 
	THEN 转向步骤2;
	ELSE 认为出错,所需资源数超过宣布的最大值(自我矛盾)
(2)IF Requesti[j]<= Available[j]
	THEN 转向步骤3;
	ELSE 表示尚无足够资源,Pi需等待(现实不满足)
(3)系统试探着把资源分配给进程Pi ,并修改相应数据结构的值(假设性操作):
     Available【j】=Available【j】 -  Requesti【j】
     Allocation【i,j】=Allocation【i,j】+ Requesti【j】
     Need【i,j】= Need【i,j】-  Requesti【j】
(4)系统执行安全性算法,判断新的资源分配状态是否是安全的。即:找一个安全序列,使这些进程按顺序执行完)如果能够找到,则将假设操作真正实施完成资源分配。

找安全序列的过程:

从 Finish[i] = false 的进程集合中找一个进程
           IF Need[i,j] <= work[j]
	THEN  执行步骤 a;
	ELSE  执行步骤 b; 
a) 假设Pi获得资源顺利执行完,释放出分配给它的资源,修改相应的值:
     work【j】  = work【i】+ Allocation【i,j】;
     Finish【i】= true;
     goto step (2); //返回去继续找下一个进程。
b)当算法不再在(2)、a)步间循环找进程,到达本步时,若所有Finish[i]=true都满足,则表示所有进程都按某个顺序执行完了,系统处于安全状态;否则,系统当前所处的资源分配状态是不安全状态。

利用资源分配图简化法来检测死锁:
1.在资源分配图中找出一个既不阻塞又非独立的进程结点Pi,在顺利的情况下运行完毕,释放其占有的全部资源。
2.由于释放了资源,这样能使其它被阻塞的进程获得资源继续运行。消去了Pi的边。
3.经过一系列简化后,若能消去图中所有边,使结点都孤立,称该图是可完全简化的。
S状态为死锁状态的充分条件是当且仅当S状态的资源分配图是不可完全简化的。<死锁定理>
在这里插入图片描述

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值