问题标签 [livelock]

从操作系统概念

5.8.2 使用显示器的餐饮哲学家解决方案

接下来，我们通过提出一个解决哲学家进餐问题的无死锁解决方案来说明监视器的概念。这个解决方案施加了一个限制，即只有当两个筷子都可用时，哲学家才能拿起她的筷子。为了编写这个解决方案，我们需要区分可能找到哲学家的三种状态。为此，我们引入以下数据结构：

state[i] = EATING只有当她的两个邻居不吃饭时，哲学家 i 才能设置变量：(state[(i+4) % 5] != EATING)并且 (state[(i+1) % 5] != EATING).

我们还需要声明

这允许哲学家 i 在她饿了但无法获得她需要的筷子时延迟自己。

图 5.18 哲学家就餐问题的监视器解决方案。

每个哲学家在开始吃饭之前都必须调用这个操作 pickup()。这一行为可能会导致哲学家进程的暂停。手术顺利完成后，哲学家就可以吃饭了。在此之后，哲学家调用该 putdown()操作。

很容易证明，该解决方案确保没有两个邻居同时进食，并且不会发生死锁。

然而，我们注意到，哲学家有可能饿死。我们不提供此问题的解决方案，而是将其作为练习留给您。

为什么监控解决方案没有死锁？

为什么哲学家会饿死？

这个问题的解决方案是什么？

谢谢。

遇到了与异步有关的有趣活锁情况。

考虑下面的代码，它会导致活锁并执行 1 分钟，即使有用的有效负载几乎不需要运行。执行时间大约为 1 分钟的原因是我们实际上会达到线程池增长限制（大约每秒 1 个线程），因此 300 次迭代将使其运行大约 5 分钟。

这不是简单的死锁，我们在一个环境中同步等待异步操作，SyncronizationContext只允许在单个线程上调度作业（例如 WPF、WebAPI 等）。下面的代码重现了控制台应用程序上的一个问题，其中没有明确SynchronizationContext的设置并且任务正在线程池上调度。

我知道这个问题的“解决方案”是“一路异步”。实际上，我们可能不知道开发者内心深处的某个地方SyncMethod通过以阻塞方式等待它释放此类问题来抑制异步（即使他可能会通过替换来使其至少不会死锁） 。SynchronizationContext

当无法选择“一路异步”时，您对处理此类问题有何建议？除了明显的“不要一次产生这么多任务”之外，还有其他东西吗？

这是一个输出。请注意所有异步延续如何停滞近一分钟，然后突然继续执行。

我一直在阅读 Java 并发实践。我看过一份声明说：

在单线程程序中不会发生死锁、活锁或饥饿等活性故障。

但是，让我们看一个例子。如果单线程应用程序在渲染视图之前发出 I/O 请求，并且 I/O 请求在概念上/理论上需要无限时间。单线程应用程序确实取得了进展并阻止了自己，最终“没有好事发生”。

我的问题是，这是否只是单线程程序中可能发生活性失败的证据？或者我可能错误地理解了活性失败？

在一个.html.erb文件中，我有<img src=<%= asset_path "logo.png" %> >并且它在页面上运行良好。我有一个渲染这个 ERB 文件的集成测试，当它渲染该行时，测试挂起并且处理器使用率在一个内核上达到 100%。

这是链轮错误吗？是不是我有其他不合适的地方？

编辑：这是我的测试：

So, I’m studying Paxos and the Professor made this question:

Assume that acceptors do not change their vote. In other words, if they vote for value v in round i, they will not send learn messages with value different from v in larger rounds. Show that Paxos does not work any more (it can reach a livelock).

I’ve reasoned about this for the entire day, but I’m not understanding how can the livelock arises and so my colleagues.

Does anyone have a clue?

VisualVM 能够检测死锁：从正在运行的程序中获取死锁检测或在 Java 中转储

VisualVM 是否能够检测活锁？如果不能自动执行，哪些操作可能有助于揭示活锁？

我读过 Livelock 是这里的资源匮乏的特例。我也读过 Livelock Process are not in a waiting state here。

A/c to Galvin Book on OS，饥饿是无限期等待的进程，无论是获取资源还是被调度程序调度，还是在信号量的队列中等。

我的问题：在任何情况下，进程是否有可能在没有饥饿的情况下遭受活锁？如果有人愿意说不并对此有解释，我会要求你一次通过这里提到的方案。对于那个方案，我不认为存在饥饿，但显然存在活锁。我已经解释了我对下面提到的 cs.se 链接的想​​法。

我已经在这里询问了我对 cs.se 的具体疑问，但还没有任何回应。

活锁的好例子？给出了活锁的一个很好的例子，它在编写花哨的代码以避免死锁情况时发生。线程获取锁A，然后尝试获取锁B。如果锁B不空闲，它会释放锁A，然后在随机时间后，获取锁A并再次尝试获取锁B。
我的问题是，我有一个正在运行的代码很多线程。如何检测是否存在活锁情况，以及哪些线程是活锁？
有人说没有工具支持。在哪种情况下，我们注定要永远和活锁一起生活？我想至少应该可以通过读取线程转储手动检测？是否有可能检测到是否存在活锁，它发生在哪里？是否可以使用工具、vm arg 或某种调试来查找我的应用程序是否正在经历活锁？