優先順位の低いスレッドが優先順位の高いスレッドをブロックしていると思いますか？ [閉鎖]

2つのスレッドがあり、各スレッドはSCHED_FIFOを使用して異なるリアルタイム優先順位に設定されます。スレッド調整が無効になっているため、理論的には最高の優先順位スレッドはCPUリソースを100％使用でき、低優先順位のスレッドが実行されないようにする必要があります。譲歩またはスリープモードに切り替えない低優先順位スレッドで緊密な無限ループを作成すると、優先順位の低いスレッドが実行されるとは予想されません。ただし、優先順位の高いスレッドの標準出力も停止し、実行がブロックされているように見えて混乱します。

優先順位の低いスレッドが常に優先順位を持たなければならない優先順位の高いスレッドを妨げるのはなぜですか。緊密な無限ループに関連していますか？それとも、Linuxスレッドの優先順位がどのように機能するのかを根本的に誤解していますか？

私は質問をできるだけ一般的にしようとしましたが、答えは私の特定の設定に関連している可能性があるため、ARMV7 CPUで実行されているRT Preemptパッチでカーネルバージョン4.1.33を使用しています。

---

編集する：

何の問題もなく問題を再現するために非常に簡単なテストプログラムを作成し、予想通り問題がなくなりました。これは、一部の共有リソースがより高い優先順位スレッドの実行を妨げる可能性があることを示します（以下の説明で提案されているように）。ただし、優先順位の高いスレッドがアクセスする必要があるリソースは思い出されません。

現在私の問題の1つは、どのタイプのリソースに排他的なロックが必要かわからないということです。システムクロックアクセス、ファイルシステムアクセス、stdoutアクセスなどの操作は、ロックの使用についてはわかりません。これらのうちのどれか（または私が見過ごしている同様のもの）は、より高い優先順位のスレッドの実行を妨げる可能性がありますか？