- 略
- 储存空间是有限的资源，每个数据块的到来都会占用一定的资源，而且随着更多数据块的到来，储存空间变得越来越紧张，可能会导致僵局的发生。为了避免这种情况，可以允许作业在完全储存之前开始打印，并保留释放出来的空间给该作业的其余部分，这样就可以避免僵局的发生，让作业能够更顺畅地完成打印任务。如果作业必须等到完全储存后才能开始打印，就可能会导致僵局的发生，影响作业的打印效率。
- 打印机是不可抢占的，因为它在打印作业时不允许其他作业同时进行，而储存磁盘则是可抢占的，因为它允许在磁盘空间不足时删除文件并请求用户稍后发送。
- 是，这没有任何区别。
- 假设有三个进程 A、B 和 C，以及两种资源类型 R 和 S。进一步假设资源 R 有一个实例，资源 S 有两个实例。考虑以下执行场景：A 请求 R 并得到，B 请求 S 并得到，C 请求 S 并得到（有两个 S 实例），B 请求 R 并被阻塞，A 请求 S 并被阻塞。在这个阶段，满足四个条件。然而，没有发生死锁。当 C 完成时，释放了一个 S 实例，分配给了 A。现在 A 可以完成执行并释放 R，然后 R 可以被分配给 B，B 可以完成执行。如果每种类型的资源有一个实例，这四个条件就足够了。
- "Don't block the box" 是一个预分配策略，它否定了持有和等待死锁的先决条件，因为我们假设车辆可以进入交叉口后的街道空间，从而释放交叉口。另一种策略可能是让车辆暂时进入停车场并释放足够的空间来消除交通阻塞。一些城市有交通控制策略来调控交通；随着城市街道的拥堵程度加剧，交通监管人员会调整红灯的设置，以限制进入高度拥堵区域的交通。较轻的交通流量确保资源竞争较少，从而降低交通阻塞发生的可能性。
- 上述异常情况属于“调度死锁”，因为车辆在一个循环链中等待资源，而交通控制可以有效地解决这种问题。与资源死锁不同，这种异常情况不是由竞争资源引起的，而是由车辆之间的相互等待引起的。在这种情况下，警察示意其中一辆竞争的车辆或列车前行可以打破死锁状态，而无需回滚或其他开销。
- 当一个进程持有某种资源的一些或全部单位，并请求另一种资源类型时，同时另一个进程持有第二种资源并请求第一种资源的可用单位时，如果其他进程无法释放第一种资源的单位且资源不能被抢占或并发使用，那么系统就可能发生死锁。例如，在实际内存系统中，两个进程都被分配了内存单元，第一个进程锁定了另一个资源，例如一个数据单元，第二个进程请求被锁定的数据并被阻塞，第一个进程需要更多内存以执行释放数据的代码。如果系统中没有其他进程可以完成并释放内存单元，系统中就存在死锁。
- 在资源分配图中，每个资源只能被一个进程持有，而每个进程也只能持有一个资源。如果一个资源被多个进程同时持有，或者一个进程持有多个资源，那么就会导致资源的冲突和浪费。因此，在资源分配图中，一个资源只能被一个进程持有，一个进程也只能持有一个资源，任何违反这个规则的图形都是不合法的。如果存在非法的图形，那么就需要重新设计资源分配方案，以确保资源的合理分配和使用。
- 这两个变化都不会导致死锁。两种情况下都不存在环形等待。
- 考虑三个进程 A、B 和 C，两个资源 R 和 S。假设 A 正在等待 B 持有的 I，B 正在等待 A 持有的 S，C 正在等待 A 持有的 R。三个进程 A、B 和 C 都处于死锁状态。然而，只有 A 和 B 属于循环链。
- 这显然是一种通信死锁，可以通过使 A 在一段时间后（启发式）超时并重新传输其使能消息（增加窗口大小的消息）来进行控制。然而，B 可能已经收到了原始消息和重复消息。如果窗口大小的更新是绝对值而不是差值给出的，不会发生任何损害。在这种消息上使用序列号也可以有效地检测到重复消息。
- 所有这些资源中的一部分可以被保留，仅供管理员拥有的进程使用，以便他或她可以始终运行一个 shell 和用于评估死锁并决定要终止哪些进程以使系统再次可用的程序。
- 首先，未标记的进程集合
R1 不小于或等于 A
R2 小于 A；标记 P2；；
R1 不小于或等于 A
R3 等于 A；标记 P3；；
R1 不小于或等于 A
R4 不小于或等于 A
因此，进程 P1 和 P4 仍未标记。它们处于死锁状态。
- 通过抢占恢复：在进程 P2 和 P3 完成之后，可以强制进程 P1 抢占 1 个 RS3。这将使 A = (02132)，并允许进程 P4 完成。一旦 P4 完成并释放其资源，P1 可能会完成。通过回滚恢复：将 P1 回滚到在其获取 RS3 之前备份的状态。通过终止进程进行恢复：终止 P1。
- 该进程正在请求比系统拥有的资源更多的资源。无论其他进程是否需要任何资源，它都无法获得这些资源，因此永远无法完成。
- 如果系统有两个或更多个 CPU，两个或更多个进程可以并行运行，导致对角轨迹。
- 是的。用三维空间进行整个过程。z 轴表示第三个进程执行的指令数量。
-
使用该方法来指导调度，只有在预先知道资源将在何时被索取的确切时刻时才能使用。实际上，这种情况很少发生。
- 存在一些既不安全也不死锁的状态，但这些状态会导致死锁的发生。例如，假设我们有四个资源：磁带、绘图仪、扫描仪和 CD-ROM，还有三个竞争这些资源的进程。我们可以有以下情况：
- 这个状态并不是死锁，因为仍然可以发生许多操作，例如，进程 A 仍可以获取两个打印机。然而，如果每个进程请求其剩余的资源需求，就会发生死锁。
- 进程 D 的请求是不安全的，而进程 C 的请求是安全的。
- 系统是没有死锁的。假设每个进程都有一个资源。还有一个资源是空闲的。任何一个进程都可以请求并获取该资源，这样它就可以完成并释放两个资源。因此，死锁是不可能的。
- 如果一个进程拥有 m 个资源，则它可以完成并且不会参与死锁。因此，最坏情况是每个进程都有 m-1 个资源，并且需要另一个资源。如果还剩下一个资源，一个进程可以完成并释放所有资源，从而让其余进程也可以完成。因此，避免死锁的条件是 r >= p(m-1) + 1。
- 不，进程 D 仍然可以完成。当它完成时，它会释放足够的资源来让进程 E（或 A）完成，依此类推。
- 将矩阵中的一行与可用资源向量进行比较需要 m 次操作。这个步骤必须重复 n 次，以找到一个可以完成并标记为完成的进程。因此，将一个进程标记为完成需要大约 mn 步。对所有 n 个进程重复算法意味着步骤的数量是 mn2。因此，a=1，b=2。
- 需求矩阵
-
如果 x 等于 0，我们立即发生死锁。如果 x 等于 1，进程 D 可以执行到完成。当它完成时，可用向量变为 1 1 2 2 1。不幸的是，我们现在已经死锁。如果 x 等于 2，在 D 运行后，可用向量为 1 1 3 2 1，进程 C 可以运行。在它完成并释放其资源后，可用向量为 2 2 3 3 1，这将允许进程 B 运行并完成，然后进程 A 运行并完成。因此，避免死锁的最小值 x 为 2。
- 考虑一个需要将大型文件从磁带复制到打印机的进程。由于内存的大小有限，并且整个文件无法完全放入内存中，进程将不得不循环执行以下步骤，直到整个文件被打印完毕：
获取磁带驱动器；将文件的下一部分复制到内存中（内存大小有限）；释放磁带驱动器；获取打印机；从内存中打印文件；释放打印机。
- 这会延长进程的执行时间。此外，由于在每个打印步骤之后都释放打印机，无法保证文件的所有部分都会连续打印在一页上。
- 假设进程 A 按照顺序请求记录 a、b、c。如果进程 B 也首先请求 a，其中一个进程会得到该记录，而另一个会被阻塞。这种情况始终不会发生死锁，因为获胜者现在可以完整地运行而不受干扰。对于其他四种组合，有些可能导致死锁，而有些可能不会。六种情况如下：
-
a b c 不会发生死锁；a c b 不会发生死锁；b a c 可能会发生死锁；b c a 可能会发生死锁；c a b 可能会发生死锁；c b a 可能会发生死锁。
- 由于六种情况中有四种可能导致死锁，因此避免死锁的机会为 1/3，发生死锁的机会为 2/3。
- 是的。假设所有邮箱都是空的。现在 A 发送给 B 并等待回复，B 发送给 C 并等待回复，C 发送给 A 并等待回复。现在满足了通信死锁的所有条件。
- 为了避免循环等待，给资源（账户）编号，按照账户号码的顺序进行加锁。读取输入行后，进程先锁定较小编号的账户，然后在获得锁定（可能需要等待）之后，锁定较大编号的账户。由于没有进程会等待比自己拥有的账户编号更低的账户，因此永远不会发生循环等待，因此也就永远不会发生死锁。
- 修改请求新资源的语义如下：如果进程请求新资源并且该资源可用，则获得该资源并保留已有资源。如果新资源不可用，则释放所有已有资源。在这种情况下，死锁是不可能的，并且没有危险获得新资源但失去现有资源。当然，该进程只有在释放资源是可能的情况下（例如可以在页面之间释放扫描仪或在光盘之间释放记录器）才能正常工作。
- 我给它一个 F（不及格）的评分。这个进程是做什么的？由于明显需要该资源，它只会再次请求并再次被阻塞。这比保持阻塞状态还要糟糕，在这种情况下，系统可能会记录竞争进程等待的时间有多长，并将新释放的资源分配给等待时间最长的进程。通过定期超时并重新尝试，进程会失去其优先级。
- 虚拟存储器和时间分片系统主要是为了辅助系统用户而开发的。虚拟化硬件将用户从预先设置需求、资源分配和覆盖等细节中隔离出来，同时防止死锁。然而，上下文切换和中断处理的成本相当大。需要专门的寄存器、缓存和电路。可能不会仅仅为了防止死锁而承担这种成本。
- 当一组进程被阻塞等待只有该组中其他某个进程可以引发的事件时，就会发生死锁。另一方面，处于活锁状态的进程并不会被阻塞。相反，它们继续执行，检查一个条件是否成为真，但该条件永远不会成为真。因此，除了它们所持有的资源之外，活锁状态的进程仍然会消耗宝贵的 CPU 时间。最后，进程被饥饿是因为存在其他进程以及大量新到来的进程，这些新进程的优先级比被饥饿的进程高。与死锁或活锁不同，饥饿可以自行终止，例如当具有更高优先级的现有进程终止并且没有新的高优先级进程到达时。
- 这种死锁状态是竞争同步的异常情况，可以通过资源预分配来控制。然而，进程不会被阻塞于资源。此外，资源已经按照线性顺序请求。这个异常状态不是资源死锁，而是活锁。资源预分配将防止这种异常情况发生。作为一种启发式方法，如果进程在一定的时间间隔内无法完成，则可能会超时并释放其资源，然后休眠一段随机时间，然后重试。
- 这里给出了答案，虽然有点复杂。
(a) 这是一个竞争同步异常。它也是一个活锁。我们可以称之为调度活锁。它不是资源活锁或死锁，因为站点并没有持有其他站点所请求的资源，因此不存在一个循环的站点持有资源并请求其他资源的链条。它也不是通信死锁，因为站点在独立执行，并且如果按顺序进行调度，则会完成传输。
(b) 以太网和时隙 Aloha 要求，在检测到自己的传输冲突后，站点必须等待一定数量的时间槽后重新发送。选择时间槽的间隔在每次冲突后加倍，根据流量负载动态调整。连续重传 16 次后，帧会被丢弃。
(c) 由于对信道的访问是概率性的，并且新到达的站点可以在已经多次重传的站点之前竞争并分配信道，导致了饥饿现象的发生。
- 这个异常不是资源死锁。虽然进程在共享一个互斥锁（即竞争机制），但资源预分配和死锁避免方法对于这种死锁状态都是无效的。对资源进行线性排序也无效。实际上，可以认为线性排序可能是问题所在；执行互斥锁应该是在进入临界区之前的最后一步，以及在离开临界区之后的第一步。存在一个循环的死锁状态，其中两个进程都在等待只能由另一个进程引起的事件。这是一个通信死锁。为了取得进展，如果抢占消费者的互斥锁，设置一个超时将打破这个死锁。编写仔细的代码或使用监视器进行互斥访问是更好的解决方案。
- 如果两个程序都首先请求 Woofer，计算机将陷入无限循环：请求 Woofer，取消请求，请求 Woofer，取消请求，依此类推。如果一个程序请求狗窝，另一个程序请求狗，我们将遇到死锁，它会被双方检测到并被打破，但在下一个循环中又会出现。无论哪种情况，如果两台计算机都被编程为首先获取狗或狗窝，都将导致饥饿或死锁。在大多数死锁问题中，饥饿似乎不严重，因为引入随机延迟通常会使其变得不太可能。但在这种情况下，这种方法不起作用。
05-19
122
122
07-30
“相关推荐”对你有帮助么？
-
非常没帮助 -
没帮助 -
一般 -
有帮助 -
非常有帮助
提交
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
