问题标签 [starvation]

所以，我的 Slurm GPU 队列存在问题，不时会导致工作匮乏。

基本上，我有很多节点有 1 个 GPU、2 个 GPU、3 个 GPU，只有 2 个有 4 个 GPU。情况如下：

1. 用户 A 提交 4 GPU 作业
2. Slurm 为用户 A 的作业分配一个 4 GPU 节点
3. 用户 B、C 和 D 提交 1 个 GPU 作业并全部分配到第二个 4 GPU 节点
4. 用户 E 提交了一个 4 GPU 作业，由于没有资源来满足其需求，它处于待处理状态
5. 用户 F、G、H、I...等提交 1 个 GPU 作业，用户 B、C 或 D 的任何作业完成后立即分配给 4 个 GPU 节点
6. 更多用户继续提交作业，4 GPU 节点忙于这 1 GPU 作业
7. 用户 E 4 GPU 作业永远等待，因为 4 个 GPU 永远不会一起使用

知道我已将 1 个 GPU 节点的权重设置为 1，将 2 个 GPU 节点设置为 2，将 3 个 GPU 节点设置为 3，将 4 个 GPU 节点设置为 4，以便用户优先考虑任何可用的 1 个 GPU 作业，如果不是，则为 2，如果然后不是 3，最后是 4。

有什么建议可以消除或减少这里的饥饿（自动）？我的工作要等上几周！

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

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

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

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

在我引用的以下示例中，我对如何使用两个二进制信号量 Q 和 S 来保证平等执行并造成饥饿的可能性感到困惑。

在中间示例中保证平等执行的理由是：

The second guarantees equal shares since the process that holds both Q and S will give up S to the other process before it releases Q and goes back to the top of the loop.

我真的不明白“放弃 S 到另一个过程”是什么意思。S不只是一个要递增和递减的值吗？P1 将在 S 发出信号后运行的想法来自哪里？

第三种情况的解释对我来说也没有任何意义，他说：

The third is subject to starvation, since it's possible for one process to run slightly faster than the other and monopolize the semaphores.

如果在这种情况下一个进程可以独占信号量，那么在平等执行的情况下不能说同样的话吗？从这个意义上说，是什么让这些不同？

我在 linux 上的 dotnet aspnetcore (3.1) 服务上遇到线程池饥饿问题的周期性峰值。值得注意的是，由于某种原因，在 Windows 上完全没有这个问题。

我使用 dotnet-trace 捕获跟踪并得出结论，我确实捕获了感兴趣的区域，因为事件包含多个线程启动事件。

现在我正在努力理解是什么阻塞了我的几十个线程，从而导致线程池创建了另外一百个。

我已经阅读了多个文档和文章，但仍然无法完全理解线程非活动和活动之间有什么区别。在线程时间视图中，我可以看到在非活动节点下方具有堆栈的节点。下面的例子。具体来说，该节点位于非活动节点下方。怎么解释？如果非活动意味着线程没有做任何事情的时间，为什么我会在给定时间区域内的时间桶中看到许多样本？这是否意味着这个线程实际上被阻塞在这个堆栈中？

问题：

如何配置ring-jetty-adapter来限制并发工作线程的数量？我在这里使用嵌入式码头，而不是创建 WAR 文件或类似的东西。

语境

我的数据库连接池中只有20个连接，所有请求都需要做数据库查询。目前，当服务器负载变高时，比如连续 40 个并发请求，其中 20 个将被阻塞等待 DB。然后队列将继续建立，等待将失去控制（线程饥饿）。

该:max-threads参数不符合我的要求，因为它只限制了 jettys 内部线程池的大小，它用于接受和选择器线程，而不仅仅是工作线程。

经过一些研究，我认为我需要使用的是码头 QoS 过滤器，但我无法弄清楚如何将 web.xml 配置转换为我的 clojure ring 应用程序。

定义：有界等待是指一个进程P_i一直等待进入临界区（CS），而其他进程P_j继续进入CS，尽管P_i已经表现出进入CS的兴趣。

现在，我明白了为什么锁变量机制没有限制等待，因为如果一个进程进入了一个非关键部分，那么另一个进程可能会来拿 CS，所以一个进程可能会饿死。

算法：

编辑：没有提供有关调度程序等的更多详细信息。问题是看一下这是否满足有限等待。

问题：您能否解释一下为什么禁用的中断同步机制满足有限等待（一个进程不能像锁变量机制一样饿着进入CS）？

如何在单车道桥问题上实现 FCFS 算法？

我正在研究单车道桥问题，并希望避免挨饿。

每当村民开始等待时，我想将他添加到等待队列的末尾，并且每当桥空闲时，我想将村民放在等待队列的顶部。

这是我的代码片段，无需担心饥饿且未实现 FIFO：

背景

我经常偶然发现锁定获取顺序必须与锁定尝试的实时顺序相同的情况。这些情况通常与锁一样的信号量有关。

理论

从我在“多处理器编程的艺术”中读到的内容，死锁自由和先到先得的保证足以使锁饥饿免费。死锁自由似乎在用户身上，因为他们必须记住正确解锁。我查看了pthreads 手册页上提供的可能的互斥锁类型，但它似乎没有提到任何关于锁定获取的排序。

问题

pthread mutex 是否保证饥饿自由？是否有实现（我主要关心 linux 系列和 macOS）？信号量是否保证与互斥锁具有相同的属性？