较低优先级线程似乎会阻塞较高优先级线程?

较低优先级线程似乎会阻塞较高优先级线程?

我有 2 个线程,每个线程使用 SCHED_FIFO 设置为不同的实时优先级。线程限制已被禁用,因此理论上最高优先级线程应该能够使用 100% 的 CPU 资源,从而防止较低优先级线程运行。如果我在较低优先级线程中创建一个不屈服或睡眠的紧密无限循环,我预计不会有较低优先级线程运行。然而,似乎较高优先级线程的标准输出也停止了,表明它也被阻止运行,这让我感到困惑。

为什么这个较低优先级的线程会干扰应该始终具有优先级的较高优先级线程?它与紧密的无限循环有关,还是我从根本上误解了 Linux 线程优先级应该如何工作?

我试图使问题尽可能笼统,但由于答案可能与我非常具体的设置有关,因此我使用带有 RT Preempt 补丁的内核版本 4.1.33,在 ARMV7 CPU 上运行。


编辑:

我创建了一个非常简单的测试程序来重现问题,没有任何复杂化,并且正如预期的那样,问题消失了。这表明某些共享资源可能会导致较高优先级线程无法运行(如下面的评论中所建议的那样)。但是,我想不出更高优先级线程需要访问的任何此类资源。

我现在的部分问题是我不确定哪些类型的资源需要独占锁。诸如访问系统时钟、访问文件系统或访问标准输出之类的事情是我不确定是否使用锁的常见事情。其中任何一个(或者可能是我忽略的类似的东西)可以阻止更高优先级线程的运行吗?

答案1

在我们的 Linux 系统中,如果没有运行我们的应用程序,“ktimersoftd”线程是最高优先级,实时优先级为 1。但是,我们的应用程序以及我们正在使用的第三方库都创建了更高的优先级实时线程,抢占“ktimersoftd”。事实证明,我们使用的第三方库之一依赖于软中断,这要求“ktimersoftd”线程的优先级高于第三方库中的线程。将“ktimersoftd”线程的优先级提高到实时优先级 98 解决了我们所看到的问题。

相关内容