Inversão de prioridade e herança de prioridade no FreeRTOS
A inversão de prioridade é um dos problemas mais perigosos — e ao mesmo tempo mais sutis — em sistemas de tempo real. Ela ocorre quando uma tarefa de alta prioridade fica bloqueada aguardando um recurso que está em posse de uma tarefa de baixa prioridade, enquanto uma ou mais tarefas de prioridade intermediária continuam executando normalmente. O resultado prático é que a tarefa mais importante do sistema acaba esperando indefinidamente, violando requisitos temporais e comprometendo o determinismo do sistema.
Para entender o problema de forma concreta, imagine três tarefas: T_H (alta prioridade), T_M (média prioridade) e T_L (baixa prioridade). A tarefa T_L obtém um mutex para acessar um periférico compartilhado, como uma UART. Antes que ela libere o mutex, ocorre um evento que desperta T_H, que imediatamente tenta obter o mesmo mutex. Como o recurso está ocupado, T_H é bloqueada. Em condições normais, esperaríamos que T_L fosse executada rapidamente para liberar o mutex. No entanto, se T_M estiver pronta para executar, ela preempta T_L, impedindo que esta libere o recurso. O sistema entra então em um estado onde uma tarefa de alta prioridade depende indiretamente de uma tarefa de prioridade intermediária — exatamente o cenário de inversão de prioridade.
O FreeRTOS resolve esse problema por meio do mecanismo de herança de prioridade (priority inheritance), integrado aos mutexes. Quando uma tarefa de alta prioridade fica bloqueada tentando obter um mutex, o kernel identifica qual tarefa é a proprietária atual do mutex. Se essa tarefa possuir prioridade inferior, o FreeRTOS eleva temporariamente sua prioridade para o nível da tarefa bloqueada mais prioritária. Dessa forma, a tarefa de baixa prioridade passa a executar antes das tarefas intermediárias, libera o mutex rapidamente e, em seguida, tem sua prioridade original restaurada.
Esse comportamento é completamente automático e transparente para o desenvolvedor, desde que o recurso esteja protegido por um mutex verdadeiro do FreeRTOS. É exatamente por isso que o uso de semáforos binários no lugar de mutexes para proteção de recursos é fortemente desencorajado. Sem a semântica de posse, o kernel não tem como saber qual tarefa deve herdar prioridade, tornando impossível mitigar a inversão de prioridade.
Do ponto de vista de implementação, o FreeRTOS mantém, para cada mutex, um registro da tarefa proprietária e, para cada tarefa, o seu nível de prioridade base e a prioridade efetiva atual. Quando múltiplos mutexes estão envolvidos, o kernel calcula a maior prioridade herdada necessária e aplica o ajuste de forma cumulativa. Ao liberar um mutex, o kernel reavalia se ainda existe alguma tarefa bloqueada em outros mutexes pertencentes à mesma tarefa antes de restaurar sua prioridade original, garantindo consistência e previsibilidade.
É importante compreender que a herança de prioridade não elimina todos os problemas de temporização, mas resolve especificamente a inversão de prioridade não intencional. O tempo durante o qual um mutex permanece bloqueado ainda depende do código da aplicação. Por isso, boas práticas como seções críticas curtas, evitar chamadas bloqueantes dentro de mutexes e não proteger grandes blocos de código desnecessariamente continuam sendo fundamentais para sistemas de tempo real robustos.
Na próxima seção, vamos sair da teoria e entrar na prática, apresentando exemplos completos de uso de mutex padrão no FreeRTOS, com análise detalhada do código e dos pontos críticos de projeto.
