死锁:操作系统的死锁检测算法,死锁避免算法,死锁预防算法,死锁检测
死锁是什么?
比如一条只容一个人通过的小道,两个方向都有一个人走来,都等着对方让路。
即:进程分别持有对方需要的一部分资源,同时自己需要的一部分资源被对方持有,相互等待对方释放自己需要的那部分资源的情况。
首先,死锁的出现需要4个条件全部满足,
1.互斥访问资源。即不可以同时使用一个资源。
2,持有并等待,即可以获得部分资源的同时,等待自己需要的其他资源
3,不可抢占。进程得到的资源不可以被剥夺,只可以自己释放。
4.循环等待。 进程相互等待或者多个进程循环等待。比如说A需要的资源被B持有,B需要的资源被C持有,C需要的资源被A持有。
解除死锁的方案:
一.死锁预防。(避免形成死锁出现的所有条件);
1.互斥访问资源。可以做的改变: 使得资源可同时访问。
2,持有并等待,可以做的改变:使进程间不存在等待的情况。即:一个进程在申请资源的时候,要求它此时未持有任何资源。或者,在进程开始时,要进程一次性申请自己需要的全部资源。
3,不可抢占。可以做的改变:可以抢占。一个进程不能获得所需要的全部资源时便处于等待状态,等待期间他占有的资源将被隐式的释放重新加入到 系统的资源列表中,可以被其他的进程使用,而等待的进程只有重新获得自己原有的资源以及新申请的资源才可以重新启动,执行。
4.循环等待。可以做的改变:排队。1.将资源排序,将系统中的所有资源顺序编号,将紧缺的,稀少的采用较大的编号,2.在申请资源时必须按照编号的顺序进行,一个进程只有获得较小编号的进程才能申请较大编号的进程。
二,死锁避免(在分配资源之前进行检验,确定不会出现死锁再分配资源)
方案: 每次有进程申请资源的时候,判断如果分配,是不是安全的,如果是安全的,才分配资源。
如何验证是安全的?
答案是,可以找到一个分配资源的顺序,在这个序列中,每一个进程的需求都可以得到满足。
所以要求申请资源的进程。提供自己的最大需求量,分配的时候,才能判断是否可以满足进程的需求。
银行家算法:
假设有3个资源 R0,R1,R2,
每次判断时,计算:
是否有一个正在执行的进程的还需要的资源数(need),当前的剩余资源数就可以满足?
遍历进程,
如果有可以满足的进程,
则认定该进程可以完成,此时把剩余资源的数目加上该进程已经占有的资源。
继续。
如果有不能满足的进程。
则判定不安全。
三。 死锁检测
不再预防或者避免死锁,而是允许进入死锁状态,定时调用死锁检测算法,发现死锁则采用死锁恢复机制
死锁检测算法:
每次判断时,计算:
是否有一个正在执行的进程的还需要的资源数(need),当前的剩余资源数就可以满足?
遍历进程,
如果有可以满足,且没有被标记被结束的进程,
和银行家算法一样,则认定该进程可以完成,此时把剩余资源的数目加上该进程已经占有的资源。
不同的是,会额外标记该进程为已结束。
继续。
如果有不能满足的进程,(需求量>空闲资源量)而且还没有被标记为已结束。
认为出现死锁。
否则认为没有出现死锁。
如果出现死锁,则进行死锁恢复,
抢占一些进程的资源,回退这些进程。或者按一定顺序终止全部进程。
死锁检测算法复杂度很高 N个进程,遍历N遍,M个资源,每个资源操作一次。则复杂度 O(M*N^2)
所以,一般由程序实现,而不是操作系统检测。
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· [.NET]调用本地 Deepseek 模型
· 一个费力不讨好的项目,让我损失了近一半的绩效!
· .NET Core 托管堆内存泄露/CPU异常的常见思路
· PostgreSQL 和 SQL Server 在统计信息维护中的关键差异
· C++代码改造为UTF-8编码问题的总结
· 【.NET】调用本地 Deepseek 模型
· CSnakes vs Python.NET:高效嵌入与灵活互通的跨语言方案对比
· Plotly.NET 一个为 .NET 打造的强大开源交互式图表库
· DeepSeek “源神”启动!「GitHub 热点速览」
· 我与微信审核的“相爱相杀”看个人小程序副业