避免死锁的银行家算法的实际实现方式?

多线程操作系统在进程调度(资源分配)的时候可能会发生死锁。

引起死锁的直接原因是竞争不可抢占的互斥资源。这种资源有可能是临界资源,例如打印机;也有可能是可消耗性资源,例如信号量。

引起死锁的间接原因进程推进顺序不当。即系统单独运行进程P1或者P2都没有问题,但是调度两个进程同时进行时,由于调度顺序导致两个进程竞争资源产生死锁。

-----------------------------

产生死锁的四个必要条件:

1、互斥条件。进程已经分配到的资源具有互斥性,不能同时被其他进程共享。

2、请求和保持条件。进程因为请求资源而被阻塞时仍然占有已经分配给自己的资源。

3、不可抢占条件。进程已经分配到的资源不可以被抢占,只能等进程执行完以后自己释放。

4、循环等待条件。每个进程都在等待其他进程所占有的不可抢占的互斥资源。

---------------------------------

预防死锁的协议--这几个协议都有各自的局限性,并不适用

1、破坏“请求保持条件”的第一种协议。协议规定进程在开始运行时必须一次性申请全部所需的资源。改进后,协议规定进程可以只分配当前所需资源,但是只有已分配资源全部用完并释放后才可以再次申请资源。这种改进就是把一个进程按阶段当做多个“小进程”来对待,仍然具有第一种协议的缺点,比第一种情况稍好一些。

缺点:资源严重浪费,且容易引起进程饥饿现象(即进程长时间得不到运行的机会,需要资源越多的进程越容易出现此现象);

2、破坏“不可抢占”的协议。协议规定已经持有不可抢占资源的进程在申请新资源失败后,必须释放已经持有的资源。

缺点:该方法实现复杂,且代价大。主要是因为,这种情况下进程释放某些资源时候难以保存资源的现场信息,相当于之前的工作白做了。

问题(这个不止是缺点):进程被无限推迟。一个进程申请了资源,又被迫释放资源,又申请资源,又被迫释放资源,如果这种资源恰好是现场信息不能保存的那种,那么进程执行了这么久还跟没执行一个样子。

3、破坏“循环等待条件”的协议:规定系统中的资源必须排序,且每个进程按资源序号递增的顺序申请资源。

缺点:资源的排序难以确定,增加新设备困难。

-----------------------------

目前使用的避免死锁的方法:银行家算法

先看两个定义:

不安全状态:没有办法定义什么是不安全状态,安全状态之外的全部是不安全状态。

安全状态:存在一个进程的安全安全序列,就属于安全状态。

这两个概念的实际内容跟他们的名字并不相符。准确地说,安全状态是全部安全的状态的一个子集,这个子集中的每个状态都可以用至少一个特例来证明自身状态是安全的。反之,不安全状态中也包含了本身可能安全,但是不能直接证明的状态。

 

银行家算法:

1、如果进程的Request《=进程的Need,转向步骤2;否则认为出错

2、如果进程的Request《=系统现有的Avaliable,转向步骤3;否则进程等待

3、推演此次资源分配后的系统状态

4、执行安全性算法,如果推演后的系统状态仍是处于安全状态,则执行此次分配;否则,不执行此次分配

银行家算法中最关键步骤是如何利用安全性算法判断安全状态。

教科书上介绍的安全性算法是一个个遍历看能不能找到安全序列。网上搜到的代码的实现方式都是教科书式的Demo,采用循环遍历来实现。这种方式明显不可取,即便是一台个人PC也有数十个进程同时运行,用循环来做安全性算法难道合适吗?

转载于:https://www.cnblogs.com/afraidToForget/p/6601697.html

银行家算法 1. 实验目的和要求 银行家算法避免死锁的一种重要方法,要求编写和调试一个简单的银行家算法程序。加深了解有关资源申请、避免死锁等概念,并体会和了解死锁避免死锁的具体实施方法。 2. 实验内容 1.设计进程对各类资源最大申请表示及初值确定。 2.设定系统提供资源初始状况。 3.设定每次某个进程对各类资源的申请表示。 4.编制程序,依据银行家算法,决定其申请是否得到满足。 3. 实验说明 1.数据结构 假设有M个进程N类资源,则有如下数据结构: MAX[M*N] M个进程对N类资源的最大需求量 AVAILABLE[N] 系统可用资源数 ALLOCATION[M*N] M个进程已经得到N类资源的资源量 NEED[M*N] M个进程还需要N类资源的资源量 2.银行家算法 设进程I提出请求Request[N],则银行家算法按如下规则进行判断。 (1)如果Request[N]<=NEED[I,N],则转(2);否则,出错。 (2)如果Request[N]<=AVAILABLE,则转(3);否则,出错。 (3)系统试探分配资源,修改相关数据: AVAILABLE=AVAILABLE-REQUEST ALLOCATION=ALLOCATION+REQUEST NEED=NEED-REQUEST (4)系统执行安全性检查,如安全,则分配成立;否则试探险性分配作废,系统恢复原状,进程等待。 3.安全性检查 (1)设置两个工作向量WORK=AVAILABLE;FINISH[M]=FALSE (2)从进程集合中找到一个满足下述条件的进程, FINISH[i]=FALSE NEED<=WORK 如找到,执行(3);否则,执行(4) (3)设进程获得资源,可顺利执行,直至完成,从而释放资源。 WORK=WORK+ALLOCATION FINISH=TRUE GO TO 2 (4)如所有的进程Finish[M]=true,则表示安全;否则系统不安全。 4. 参考程序 #include "string.h" #include "iostream.h" #define M 5 //总进程数 #define N 3 //总资源数 #define FALSE 0 #define TRUE 1 //M个进程对N类资源最大资源需求量 int MAX[M][N]={{7,5,3},{3,2,2},{9,0,2},{2,2,2},{4,3,3}}; //系统可用资源数 int AVAILABLE[N]={10,5,7}; //M个进程已经得到N类资源的资源量 int ALLOCATION[M][N]={{0,0,0},{0,0,0},{0,0,0},{0,0,0},{0,0,0}}; //M个进程还需要N类资源的资源量 int NEED[M][N]={{7,5,3},{3,2,2},{9,0,2},{2,2,2},{4,3,3}}; int Request[N]={0,0,0};
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值