银行家算法，死锁检测算法实践
银行家算法实践
假设资源集合R = {A,B,C}，资源类A有10个实例，B有5个实例，C有7个实例，系统某一时刻存在5个进程，且此时系统状态如下：
运行安全性检测算法：
假设P2有资源请求Request[2] = {1, 0, 2}，能否被满足？
运行安全性检测算法（自己动动手吧），得到安全序列<p3,p1,p4,p2,p0>，故可以分配满足。
死锁检测算法实践
假设资源 R = { A , B , C }， A=7，B=3，C=6，进程 P = { p0 , p1 , p2 , p3 , p4 }，某时刻状态：
运行死锁检测算法： 得到安全序列：< p0,p2,p3,p1,p4 >，且所有进程均执行结束。
假设P2有资源请求：Request[2]=(0， 0，1）。 经死锁检测算法检测后检查出死锁，并且知道参与死锁的进程为{P1，P2，P3，P4}。
注意：当看到这里的时候，可能有人会有疑问，这个序列是这样的吗？为什么我找到的是<p0,p2,p3,p4,p1>？这时，你就要注意一个问题，OS在某一个分配状态下（如本文所示的状态），其实并不只是存在一条满足条件的安全序列，他可以有多条，而我们只需要找到一条，那么就说明这一次的分配是安全的，不会发生死锁。 其次，更要注意的是，由于算法的实现是不同的，对于我们来说，我们可以跳跃式的去寻找下一次分配（比如，发现p0可以安全的得到资源并且继续运行，下一步，我们就发现可以跳到p2去分配），而计算机是不行的，他是需要严格的按照算法流程进行的，如果选择顺序探测，那么他的检测流程就是p0->p1->p2->p3->p4，若是基于上一次检测的位置（在OS的内存管理技术中我们称为下次适应），虽然依旧是顺序探测，但是当发现满足条件的进程并对其做出相应的处理后，就不需要回到p0处（从头）开始再一次的探测。 这也就是编程的思想。
下一篇：
Nginx显示500错误原因和解决方法