问题标签 [starvation]

调度方案：抢占式优先调度

情况 ：

进程 L（低优先级）获取资源（R）上的自旋锁。当仍处于临界区时，由于另一个进程 - H（更高优先级）进入就绪队列，L 被抢占。.

然而，H 还需要访问资源 R 并因此尝试获取自旋锁，这导致 H 忙于等待。因为使用了自旋锁，所以 H 永远不会真正进入 Wait 并且将始终处于 Running 状态或 Ready 状态（以防更高优先级的进程到达就绪队列），从而阻止 L 或任何优先级低于 H 的进程执行。

A) 所有优先级小于 H 的进程都可以认为处于饥饿状态

B) 所有优先级小于 H 的进程以及进程 H 都可以认为处于死锁状态。[但是，那么进程是否必须处于等待状态才能使系统被认为处于死锁状态？]

C）所有优先级小于H的进程以及进程H，都可以认为是处于活锁状态。[但是，只有H的状态不断变化，所有低优先级的进程都保持在Ready状态。如果系统处于活锁状态，所有进程的状态是否都需要不断更改（作为自旋锁的一部分）？]

D) H 单独可以被认为处于活锁状态，所有低优先级的进程都处于饥饿状态，而不是处于活锁状态。

E) H 不会进步，但不能被认为处于活锁状态。所有较低优先级的进程都处于饥饿状态，而不是处于活锁状态。

以上哪些说法是正确的？你可以解释吗？

我正在开发一个需要并行和定期检查多个资源的程序：

该findAll调用返回大约 50 个传感器的列表，但是当我运行程序时，我看到虽然在第一个周期查询了所有传感器，但在后续执行中只调用了 2-3 个（例如 - 在 20 秒、30 秒等） . 我在想，由于某些传感器比其他传感器返回得更快，它们会更早地完成任务的等待周期，并被池中的下一个线程抓取，从而使其他完成速度较慢的任务饿死。

如何确保所有任务（传感器）都得到平等对待？这里有哪些最佳实践；我应该使用作业队列还是不同的并发机制？谢谢。

因此，对于一个项目，我正在尝试检测和缓解网络上的恶意 DHCP 服务器。我已经完成了所有工作，我创建了一个脚本来构建发现数据包（使用 Scapy），如果检测到多个响应，我还有另一个脚本，它将在 DHCP 饥饿的网络上拒绝所有 DHCP 服务器，并且工作正常。

然而，我今天遇到了我的项目主管，他告诉我，我应该只对恶意的 DHCP 服务器进行 DoS，而我的脚本在此 DoS 所有 DHCP 服务器。

我不知道我会怎么做。有人有什么想法吗？

我正在使用在具有 48 个 CPU 和 250GB RAM 的主机上运行的 VirtualBox 5.1，我正在导入的虚拟机（来宾）最初具有 2 个 CPU 和 4GB 的 RAM。

在这台机器内部，我正在使用 Java 运行一个进程，该进程启动动态数量的线程来执行某些任务。

我使用以下配置运行它：

我的笔记本电脑的整个过程（2 个 CPU/4GB RAM）~ 11 秒

服务器中的虚拟机中的相同程序（15 个 CPU 和 32GB 的 RAM）~ 45 秒

服务器中的虚拟机中的相同程序（20 个 CPU 和 32GB 的 RAM）~ 100+ 秒

服务器中的虚拟机中的相同程序（10 个 CPU 和 32GB 的 RAM）~ 5+ 秒

首先，我认为我从 Java 管理线程的方式存在问题，但经过多次测试，我发现虚拟机拥有的 CPU 数量与其性能之间存在关系，最大值为 10，之后机器的整体性能变慢（CPU饥饿？）

虚拟机运行 Oracle Enterprise Linux 6.7，主机运行 Oracle Enterprise Linux 6.9

我在虚拟机文档中找不到关于 CPU 数量的任何硬性限制。

是否需要设置一个设置来启用/利用 VirtualBox 实例中的 10 多个 CPU？

商业逻辑

我们有以下业务逻辑要完成：

100 万次：

1. 下载索引 i 中的文件
2. 解压文件
3. 从文件中提取一些信息
4. 删除文件

当前的 Akka 解决方案

我们目前拥有的 Akka 解决方案创建了 100 万个演员，他们负责下载一个文件，一旦完成，他们就会创建一个演员来处理步骤 2、3、4。

问题

运行该过程后，我们遇到了 Akka 将下载 actor 置于最高优先级的情况，而其余的 actor 则处于饥饿模式。

我们知道，由于下载actor不断下载，机器磁盘已满，但其他actor没有机会扫描和删除文件。

问题

1. 有没有办法强制 Akka 不要让演员链中的演员挨饿？
2. 有没有办法告诉下载参与者等到它收到可以继续的通知（例如，磁盘中不超过并行 1000 个文件）

谢谢。

node.js是否有关于事件循环中任何单个请求的延迟的明确考虑？AFAICT 每个 IO 调用都会返回一个eventEmitter发出事件的事件。所有事件的处理都是通过使用多路复用的pipe。因此，对于重要event请求需要处理的内容可能会被放置在管道中太远。是否有某种优先级队列可用于安排 eventHandlers 的执行顺序？

这就是我首先问这个问题的原因。我决定给出一个 gist.github 链接，因为原因很长并且与技术问题有关

我正在对一个 IIS 应用程序进行一些性能/可扩展性测试，该应用程序有时似乎会在生产中慢下来。我能够使用 NUnit 始终如一地重现缓慢。

CPU 和内存在测试期间不会出现峰值，或者在生产中出现缓慢时。我强烈怀疑应用程序正在遭受线程饥饿，因为它似乎不是导致瓶颈的 CPU、内存、I/O 或数据库访问。我确实看到了线程饥饿的迹象；例如，NLog 的异步日志文件写入往往有很长一段时间的静默，然后是带有较旧时间戳的活动突发（即较低优先级的线程正在等待线程释放以便写入）。

我可以采取哪些步骤来明确确定应用程序确实是线程匮乏的，并且（假设是这种情况）查明导致问题的系统的确切区域？

编辑

我没有提到几乎所有的代码都是同步的（它是一个遗留系统）。

在著名的 Spark Streaming 字数统计示例中，Spark 配置对象的初始化如下：

在这里，如果我将主控更改local[2]为local或不设置主控，我不会得到预期的输出，实际上字数统计根本不会发生。

评论说：

“主人需要 2 个核心来防止饥饿情况”，这就是他们完成 setMaster("local[2]") 的原因。

有人可以解释一下为什么它需要 2 个内核以及什么是饥饿场景吗？

那里：

使用 ignite 缓存时出现错误。我的系统选择了一个使用zookeeper的主节点，并且有许多从节点。主进程点燃缓存过期值并放入点燃队列。从节点将数据提供到点燃缓存中使用streamer.addData（k，v）并消耗点燃队列。我的代码是：

点燃缓存和流光：

master 处理缓存中过期的条目，并放入 ignite 队列：

从属消耗队列。

但我在几个小时后运行后得到了下面的错误日志：

Q - 如果系统内存不足，当系统认为内存不足时，作业通常会在 Linux 中移动到磁盘。（即交换）以这种方式运行的操作系统是否具有因主内存争用而死锁的进程？进程会被饿死吗？讨论

我尝试的答案（不正确）

是的，主内存是可重用的资源。如果有 3 个进程 AB 和 C 都在竞争主存。每次分配主内存中的新位置时，其中任何一个都有可能被忽略。饥饿。

此外，如果死锁的 4 个条件在不同的进程竞争主内存的情况下满足，则可能会发生死锁。（循环等待，互斥失败，保持等待，不抢占）

我的回答不正确，我得到了一半的分数，但没有纠正我的错误。有人可以对问题的两个部分给出完整的答案，以便我看到我的错误吗？