低優先級執行緒似乎阻塞了高優先級執行緒？
我有 2 個執行緒，每個執行緒都使用 SCHED_FIFO 設置為不同的實時優先級。執行緒限制已被禁用，因此理論上最高優先級的執行緒應該能夠使用 100% 的 CPU 資源，從而阻止低優先級的執行緒執行。如果我在不產生或不休眠的較低優先級執行緒中創建一個緊密的無限循環，我希望沒有較低優先級的執行緒可以執行。然而，似乎更高優先級執行緒的標準輸出也停止了，表明它也被阻止執行，這讓我感到困惑。
為什麼這個較低優先級的執行緒會干擾應該始終具有優先級的較高優先級的執行緒？它與緊密的無限循環有關，還是我從根本上誤解了 Linux 執行緒優先級應該如何工作？
我試圖使問題盡可能籠統，但由於答案可能與我非常具體的設置有關，我使用的是核心版本 4.1.33 和 RT Preempt 更新檔，在 ARMV7 CPU 上執行。
編輯：
我創建了一個非常簡單的測試程序來重新創建問題而沒有任何復雜性，並且正如預期的那樣，問題消失了。這表明某些共享資源可能會導致更高優先級的執行緒無法執行（如下面的評論中所建議的）。但是，我想不出更高優先級執行緒需要訪問的任何此類資源。
我現在的部分問題是我不確定哪些類型的資源需要獨占鎖。諸如訪問系統時鐘、訪問文件系統或訪問標準輸出之類的事情是我不確定是否使用鎖的常見事情。其中任何一個（或者可能是我忽略的類似的東西）會阻止更高優先級的執行緒執行嗎？
在我們的 Linux 系統中，沒有我們的應用程序執行，“ktimersoftd”執行緒是最高優先級，實時優先級為 1。但是，我們的應用程序以及我們正在使用的第三方庫都創建了更高的優先級實時執行緒，搶占“ktimersoftd”。事實證明，我們使用的第三方庫之一依賴於軟中斷，這要求“ktimersoftd”執行緒的優先級高於第三方庫中的執行緒。將“ktimersoftd”執行緒的優先級提高到實時優先級 98 解決了我們看到的問題。