Eu tenho 2 threads, cada um configurado para uma prioridade em tempo real diferente usando SCHED_FIFO. A limitação de thread foi desativada, portanto, teoricamente, o thread de prioridade mais alta deve ser capaz de usar 100% dos recursos da CPU, evitando que threads de menor prioridade sejam executados. Se eu criar um loop infinito apertado no encadeamento de prioridade mais baixa que não produza ou durma, espero que nenhum encadeamento de prioridade mais baixa seja executado. No entanto, parece que a saída padrão do segmento de prioridade mais alta também pára, indicando que ele também é impedido de ser executado, o que me confunde.
Por que esse segmento de menor prioridade pode interferir em um segmento de maior prioridade que deve sempre ter prioridade? Isso tem algo a ver com o loop infinito apertado, ou eu estou entendendo mal como as prioridades de thread do Linux devem funcionar?
Eu tentei fazer a pergunta o mais geral possível, mas como a resposta pode estar relacionada à minha configuração específica, estou usando o kernel versão 4.1.33 com o patch RT Preempt, rodando em uma CPU ARMV7.
EDITAR:
Eu criei um programa de teste morto simples para recriar o problema sem qualquer complicação e, como esperado, o problema desapareceu. Isso indica que alguns recursos compartilhados provavelmente culpariam o segmento de maior prioridade não ser capaz de executar (como sugerido nos comentários abaixo). No entanto, não consigo pensar em nenhum desses recursos que o segmento de maior prioridade precisaria acessar.
Parte do meu problema agora é que não sei quais tipos de recursos exigiriam um bloqueio exclusivo. Coisas como acesso ao relógio do sistema, ou acesso ao sistema de arquivos, ou acesso à saída padrão, são coisas comuns que eu não tenho certeza se um bloqueio é usado. Poderia algum desses (ou talvez algo semelhante que eu esqueci) impedir que o segmento de maior prioridade seja executado?