问题标签 [starvation]

我一直在研究一个问题，其中具有相关 dao 的主工作流表（被多个线程击中很多）正在努力以公平的方式跟上请求 - 几乎就像资源匮乏一样。

这些线程都负责从各种外部系统中提取数据（其中大约 5 个）。

这里的问题是，当一个线程一次获得如此多的信息时 - 它会向表发送请求，从而使其他线程竞争访问/资源。因此，它们通常会超时并需要重新启动。

是否有任何机制或策略来管理这种事情。我正在考虑（这是我最初的第一个想法）创建某种形式的阻塞列表，所有线程也可以添加它（可能在先到先得的基础上），然后以这种方式过滤 SimpleJdbcOperations。

我愿意接受任何解决此类问题的理论，这些理论被认为是此类问题的标准。

谢谢

众所周知，优先级队列可以以最简单的形式为较低优先级的项目造成饥饿。例如，假设我们在优先级队列中有以下项目以优先级顺序递增：

现在，如果我们在优先级队列（BE）中接收到具有较高优先级的项目的一致流，我们可能永远不会处理较低优先级的数据包（A）。我想知道有什么算法可以解决这个问题？

我想到的一个简单方法是根据优先级限制对不同项目类型的处理。例如，我们将每种类型的数据包处理限制为2 ^ priority. 所以对于上表，在处理完 16 种Item E类型后，我们将处理最多 8 种类型Item D，最多 4 种Item C，最多 2 种Item B，最多 1 种，Item A然后再开始处理Item E。这将防止不同项目类型的饥饿。

这是一个简单的方法，但我想知道是否有其他著名的算法来解决这个问题。有更好的算法或解决方案的想法吗？

我正在学习中断，但无法理解当中断过多到 CPU 无法处理前台循环或完成现有中断时会发生什么。我通读了这篇文章https://www.cs.utah.edu/~regehr/papers/interrupt_chapter.pdf但不完全理解调度程序将如何提供帮助，如果中断太多？

如果不能错过中断，我们是否会切换到更快的 CPU？

我有一个应用程序，其中几个线程共享一个互斥锁。

一个密集（T1）其他较小（T2，T3..）。我有一个例子，其中需要锁的线程在成功获取锁之前经常被阻塞 100 秒。

获取锁的线程（T1 so）通常以以下方式进行：

globalMutex_然后定期释放。

奇怪的行为：

T1在总共 100 秒的时间内系统地获得了锁，而其他线程根本没有获得锁

（在其他线程中，我有相同的模式，但其他函数的调用频率较低）

问题： 有什么可以解释的？这是正常行为吗？

上下文： 我在 Windows 10 / 最新版本的 Visual Studio / 64 位 / GUI 应用程序下

注意： 即使我把T2放在了高优先级，情况也是一样的。

我一直在 wikipedia 上寻找解决哲学家就餐问题的方法。 资源层次解决方案

我了解它的工作原理以及打破循环结构如何防止死锁，但解决方案如何防止饥饿？一个或几个线程不能继续运行，而一些线程无法取得进展吗？

如果不是，是什么阻止了这种情况的发生？

实施：

这是哲学家班

这是分叉类

I'm writing a starvation simulation in Java. However, when I run it, it simply doesn't work almost any time. I'm working on MacOS. The code is like:

}

and the SharedObject just simulates long running operations looks like this:

I wonder what is the mistake in this code.

我正在尝试向两种类型的线程授予对共享资源的访问权限。当且仅当该线程属于同一类型时，它才能被多个线程访问。让我们考虑黑人和白人。当资源被白人使用时，黑人不能使用，反之亦然。

我尝试使用信号量来实现这一点。一旦黑人试图访问该资源，它将增加黑人的数量，如果该数字为 1，它将阻止白人访问它。

问题：当每种类型有超过 1 个线程时（在我的情况下，id 为 0 的线程从未使用过它），就会出现明显的饥饿。我试图通过添加一个额外的信号量作为队列来解决这个问题。

观察：这非常类似于读者-作者问题，除了有一个多对多的访问标准。（它可以被同一类型的多个线程使用）最近我一直在为这个问题头疼，我似乎不明白我应该如何解决这个问题。

现在，对于一些代码：

免责声明：这篇文章包含对以下答案所做的编辑，所有学分归其各自所有者所有。

我正在尝试实现一个问题，该问题指出资源可能被两种类型的线程使用。每种类型可以有更多的线程。（4 个白色类型的螺纹和 6 个黑色类型的螺纹）。任意数量的黑人可以同时使用该资源。白人也一样。我仍然无法解决这个问题......

我尝试使用互斥锁来实现这一点。我还想考虑此实现可能存在的饥饿问题，因此我决定检查是否已达到某种类型的服务线程数，从而允许其他类型工作。我似乎无法实施最新的。

我还想考虑到，每当其他类型想要使用资源时，它必须等待轮到它，以及其他类型完成使用资源。

编辑：我尝试使用@Nominal-Animal的解决方案，但似乎有时也会出现这种死锁。此外，我在结构中添加了缺少的转弯。现在，我有一些额外的问题：

• 这似乎是正确的，但不起作用，为什么？
• 为什么isBLack里面的参数需要双重否定bwlock_lock()

现在，对于一些代码：

这是使用编译的gcc -g -o ba blacks_whites.c -Wall -Wextra -pthread。

Question about ScheduledExecutorService.shceduleAtFixedRate - I schedule taskA to run every 500 millis, which blocks for 1000 millis. Now subsequent executions aren't gonna wait the extra 500 millis, but rather commence immediately after the previous one.

taskA acquires an intrinsic lock, which is also (attempted) acquired by a different thread. Since intrinsic locks have no fairness guarantees this thread is running a risk of starvation, so here's my question: Is there a good/clean way to avoid this risk? E.g. schedule the task to run every 1500 millis (doesn't sound very waterproof)? Or do we expect the lock acquisition to exhibit a kind of "amortized fairness"?

饥饿和护航效应之间的唯一区别是护航效应主要定义在FCFS调度算法上，而饥饿是基于优先级的调度吗？

我研究了这两种效果，但找不到比较。这是基于我在大学学位中学到的操作系统理论。