标签：操作系统 现代 死锁 进程 银行家 资源管理 资源 请求
3.5.1 The Banker's Algorithm (Dijkstra) for a Single Resource单类资源的银行家算法
这个算法很简单：保持安全状态！现在我们假设，在开始执行之前，所有的进程已经开始并且声明了它所需要的所有资源。更详细的说，银行家算法的具体流程如下：
- 执行前需要确保系统安全。也就是说需要检查以下进程声明的资源数量是否超过了资源管理器所拥有的最大资源数，如果存在这样的进程就需要将其标记为出错，因为即便这个进程运行起来，它也会一直阻塞永远无法结束，那么在开始前资源管理器就会拒绝这个进程；
- 当资源管理器收到一个进程的资源请求时，先假装同意这个进程，然后检查结果的状态是否安全，如果安全就批准这个进程的资源请求，否则该进程就会被阻塞；
- 当一个资源被返回时，资源管理器检查第一个被挂起的资源请求是否可以被批准，如果可以批准就分配资源，否则按顺序依次检查后续被挂起进程的资源请求能否被批准。
Homework 18
|
Free: 2 |
||
|
Has |
Max |
|
|
A |
1 |
6 |
|
B |
1 |
5 |
|
C |
2 |
4 |
|
D |
4 |
7 |
21. Take a careful look at Figure 6.11(b), which is reproduced on the right.
If D asks for one more unit, does this lead to a safe state or an unsafe one?
What if the request came from C instead of D?
显然，如果D再请求任何的资源，系统就会进程不安全状态，因为如果批准的话系统已经完全没有办法满足其余任何进程的资源请求了（进程C需要两个）。如果C和D的资源请求一起到达资源管理器的话，显然资源管理器会先判断如果将资源给D之后系统会进入不安全状态，因此进程D会被阻塞，而进程C的请求会被满足。等待C运行结束后资源管理器拥有了4个可用资源，此时可以满足D的运行需求，将其中3个分配给D。
3.5.2 The Banker's Algorithm for Multiple Resources多类资源的银行家算法
在较高的层次上，该算法与单个资源类型的算法相同：保持安全状态。但在这种新环境下，什么是安全状态？相同的定义（如果进程以特定的顺序运行，它们将全部终止）。
检查安全性的想法与上述相同。区别在于，要判断是否有足够的空闲资源供进程终止，管理器必须检查，对于所有资源类型，空闲单元的数量至少等于进程的最大额外需求。
Homework 19
考虑一个由银行家算法管理的总共包含12单位资源R和24单位资源S的系统。有三个过程P1 P2 P3。P1声明需要0单位的R和12单位的S，写成 ； ； 。目前P1持有4个单位的S，P2持有8个单位的R，P3持有8个单位的S，没有未完成的请求。
先分析，资源管理器知道目前只剩余4个R和12个S。
A. 此时，P1可以要求银行家提供的最大S单位数是多少？
8个S，因为P1拿到8个后S就可以直接运行然后释放所有的资源。
B. 如果是P2提出请求，银行家提供的最大S单位数是多少？
4个S，显然P2拿到大于4个S之后会完全阻塞P1和P3最后形成死锁。
C. 如果是P3提出请求，银行家提供的最大S单位数是多少？
4个S，由于P2已经拿到了8个R，P3的R资源已经不可能在P2结束前被满足，因此P3不能优先于P1运行，P1运行最少需要8个S，因此最多也只能给P3进程4个S。
Remark: A problem for class discussion.
考虑一个由银行家算法管理的包含4个单位R资源和10个单位S资源的系统，有三个进程X Y Z，分别声明了X(3,2); Y(2, 8); Z(4, 8)，目前X持有1个R和2个S，Y啥也没有，Z持有4个S。
|
System with 4 units of R; 10 of S |
|||
|
process |
Initial claim |
Current alloc |
might |
|
X |
(3,2) |
(1,2) |
(2,0) |
|
Y |
(2,8) |
(0,0) |
(2,8) |
|
Z |
(4,8) |
(0,4) |
(4,4) |
|
total |
(1,6) |
||
|
available |
(3,4) |
||
在当前情况下，X, Y, Z分别能请求多少个单位的资源且资源管理器可以允许？
X：可请求2个R；
Y：只可请求2个S；
Z：可请求1个R和4个S；
- 当前情况下系统处于安全状态：X可结束，剩余的资源数量变为(4, 6)；然后Z可结束，剩余资源数量变为(4, 10)，最后Y结束；
- 银行家会将两个R分配给X（也是X可以请求的最大资源数量），此时系统处于安全状态，所以第一个问题的答案是请求2个R；
- 显然银行家不会给Y分配任何资源，因为当Y获取了资源后，Y和Z全都无法完成，系统进入了不安全状态。当Y拿了一个R后，系统能提供的资源数量变为(2, 4)，Y还需要(1, 8)，虽然X能结束，但是结束后系统资源剩余(3, 6)，Y需要(1, 8)，Z需要(4, 4)谁都无法满足；所以第二个问题的答案是请求0个R，但是能拿两个S；
- 假如银行家给了Z 2个R，那么X无法完成了，全部卡死；
- 加入银行家给了Z 1个R，此时X可以完成，并且Y，Z也可以完成，所以第三个问题的答案是请求1个R。
Limitations of the Banker's Algorithm银行家算法的局限性
- 用户通常不知道他们的进程会发出的最大请求，所以他们会保守地估计（即，使用大的数字进行声明），这使得资源管理器变得非常保守。
- 新进程的到来会带来问题（但不像Tanenbaum说的那么糟糕）。进程的请求必须小于系统中资源的总单元数，如果不是，则该进程不被系统接受。因为没有新进程的状态是安全的，所以加入了可被允许的新进程的状态也是安全的（新进程进入时持有的资源是0）！只需使用银行家原来的流程顺序，并将新流程放在最后。确保公平需要更多的工作，但也不是太难（每小时停止接受新进程，直到所有当前进程完成）。
- 资源可能变得不可用（例如，CD-ROM驱动器可能损坏），这可能会导致不安全状态和死锁。
Homework 20
26. A system has four processes and five allocatable resources. The current allocation and maximum needs are shown on the right.
What is the smallest value of x for which this is a safe state?
There is a typo in the book's table. A has claimed 3 units of resource 5, but there are only 2 units in the entire system (A has 1 and there is 1 available). Change the problem by having A both claim and be allocated 1 unit of resource 5.
|
Allocated |
Maximum |
Available |
Might Needed |
|
|
Process A |
1 0 2 1 1 |
1 1 2 1 3 |
0 0 x 1 1 |
0 1 0 0 2 |
|
Process B |
2 0 1 1 0 |
2 2 2 1 0 |
0 2 1 0 0 |
|
|
Process C |
1 1 0 1 0 |
2 1 3 1 0 |
1 0 3 0 0 |
|
|
Process D |
1 1 1 1 0 |
1 1 2 1 1 |
1 1 3 2 1 |
0 0 1 0 1 |
|
SUM |
4 2 4 4 1 |
4 2 4+x 4 2 |
0 0 x=2 1 1 |
|
X的值最少是多少？显然我们先要找到一个安全状态下可以运行的进程顺序，仅通过设置X值可以被满足的只有进程D，那么我们先假设X= 1满足D运行，当进程D结束后，系统中的剩余资源为1 1 2 2 1，此时我们发现阻塞了，只有进程C可以通过操作x的数量解除阻塞，所以实际上X=1是不够的，应当将X设为2。
注意：这题里进程A不应该被允许执行，因为系统中只有2个单位的5号资源，但是A声明了它需要3个！
29. A distributed system using mailboxes has two RPC primitives send and receive. The latter primitive specifies a process to receive from and blocks if no message from that process is available, even if messages are waiting from other processes. There are no shared resourced, but processes need to communicate frequently about other matters. Is deadlock possible? Explain.
使用邮箱的分布式系统有两个RPC原语：发送Send和接收Recv。后一个原语指定要接收的进程，如果来自该进程的消息不可用，则阻塞该进程，即使来自其他进程的消息正在等待。没有共享资源，但是进程需要频繁地就其他事项进行通信。死锁可能吗?解释一下。
显然是可能的，如果存在两个进程都需要等待对方给自己发送消息，但是由于两个进程都被Recv原语阻塞，那么就不可能有一方发送Send来解除当前互相等待的死锁。实现了死锁产生的最重要的也就是第四个条件，形成了一个有向循环依赖。
38. 灰姑娘和王子要离婚了。为了分割他们的财产，他们商定了以下算法。每天早上，双方都可以给对方的律师寄信，要求对方提供一项财产。由于信件需要一天才能送达，所以他们同意，如果双方发现他们在同一天申请了相同的物品，那么会在第二天发送一封取消申请的信件。他们的财产是他们的狗，低音提琴。低音鸟的狗窝，他们的金丝雀，啾啾和啾啾的笼子。动物们喜欢他们的房子，所以大家一致同意，任何将动物和房子分开的财产分割都是无效的，需要整个分割从头开始。灰姑娘和王子都非常想要低音提琴。为了能（各自）度假，双方都在电脑上设置了处理谈判的程序。当他们度假回来时，电脑还在谈判。为什么？死锁可能吗？饥荒可能吗？
以下有几种产生死锁的可能性，两个人都有点傻且不肯让步，那就会一直请求低音提琴，比如第一天灰姑娘和王子都发送了想要低音提琴的请求。然后由于狗子和狗窝不可分割，鸟和鸟笼不可分割此时我们可以把动物想象成资源R，窝想象成资源S，就是当一个进程同时拥有一项R和S时才能完成分割，那么第二天发出的请求很有可能就是王子要金丝雀，灰姑娘要鸟笼子，此时第一天的要求返回，谁也拿不走低音提琴，然后第三天两个人又发送低音提琴的请求，然后就开始了永无止境的循环。此时狗子和狗屋就被饿死了，只有低音提琴和金丝雀在被不断地请求然后被驳回。这个驳回操作虽然打破了死锁，但是并不解决根本问题，相当于破坏进程重新运行，该出问题还是会出问题。
3.6 Other Issues其他主题
3.6.1 Communication Deadlocks通信死锁
我们主要考虑实际的硬件资源，如打印机，但也考虑了更抽象的资源，如信号量。还有其他的可能性。例如，服务器经常等待客户机发出请求。但是如果请求msg丢失了，服务器仍然在等待客户端，而客户端正在等待服务器响应(丢失的)最后一个请求。每个人都会等待对方一辈子，一个僵局。解决这种通信死锁的方法是使用一个超时（Timeout），以便客户端最终确定消息丢失并发送另一个消息。
但事情远没有那么简单：msg可能被严重延迟，现在服务器将收到两个请求，这可能是糟糕的，并且可能发送两个回复，这也可能是糟糕的。这就产生了我们不研究的通信协议这个严肃的课题。
3.6.2 Livelock活锁
当资源不可用时，进程可以再次尝试获取资源，而不是阻塞资源。现在假设进程A拥有打印机，进程B拥有CD-ROM，并且每个进程还需要其他资源。A会反复要求CD-ROM, B会反复要求打印机。这两个进程都不能成功，因为另一个进程持有所需的资源。因为没有进程被阻塞，所以这不是技术上的死锁，而是一个相关的概念，称为livelock。
3.6.3 Starvation饥饿
通常，FCFS是一种很好的解决饥饿的方法。这通常是通过优先级老化和选择优先级最高的进程来获取资源来实现的。也可以周期性地停止接受新进程，直到所有旧进程获得它们的资源。
标签：操作系统,现代,死锁,进程,银行家,资源管理,资源,请求 来源： https://www.cnblogs.com/thomaszhong/p/15771322.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。