低优先级线程似乎阻止高优先级线程？

Question

我有两个线程，每个线程使用SCHED_FIFO设置不同的实时优先级。线程节流已被禁用，因此理论上最高优先级线程应该能够使用100%的CPU资源，从而防止优先级较低的线程永远运行。如果我在低优先级线程中创建了一个不产生或休眠的无限循环，那么我希望没有任何低优先级线程能够运行。但是，似乎更高优先级线程的标准输出也停止了，这表明它也无法运行，这使我感到困惑。

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

我试图使这个问题尽可能笼统，但由于答案可能与我非常具体的设置有关，所以我使用了内核版本4.1.33和RT抢占补丁，运行在一个ARMV7 CPU上。

编辑：

我创建了一个非常简单的测试程序来重新创建这个问题，没有任何复杂，正如预期的那样，问题消失了。这表明某些共享资源可能是高优先级线程无法运行的原因(如下面的注释所示)。但是，我想不出高优先级线程需要访问的任何这样的资源。

我现在的部分问题是，我不确定什么类型的资源需要独占锁。对系统时钟的访问、对文件系统的访问或对标准输出的访问都是我不确定是否使用锁的常见问题。这些(或者类似的东西，我忽略了)中的任何一个能阻止高优先级线程的运行吗？

Answer 1

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