Mutex versus Semáforo: diferenças conceituais que impactam o projeto
Embora mutexes e semáforos sejam frequentemente confundidos — especialmente por quem vem de sistemas bare-metal ou de bibliotecas POSIX simplificadas — eles resolvem problemas diferentes e possuem semânticas distintas no FreeRTOS. Entender essa diferença é crucial para projetar sistemas estáveis, previsíveis e realmente compatíveis com requisitos de tempo real.
Um semáforo é, conceitualmente, um contador de permissões. Ele indica quantas instâncias de um determinado recurso estão disponíveis ou quantos eventos ocorreram. No FreeRTOS, semáforos são muito usados para sinalização: uma interrupção sinaliza uma tarefa, uma tarefa acorda outra, ou um driver indica que um buffer foi preenchido. O ponto-chave é que qualquer contexto pode “liberar” um semáforo, independentemente de quem o “pegou”. Essa característica torna o semáforo adequado para comunicação e sincronização entre tarefas e ISRs (Interrupt Service Routines), mas inadequado para representar posse de um recurso exclusivo.
O mutex, por outro lado, representa propriedade. Quando uma tarefa obtém um mutex, ela se torna a dona do recurso protegido. Somente essa mesma tarefa pode liberá-lo. Essa noção de posse é essencial para que o kernel possa aplicar corretamente mecanismos como a herança de prioridade. Sem essa semântica, o RTOS não consegue identificar qual tarefa está bloqueando outra de maior prioridade, o que inviabiliza qualquer tentativa de correção automática da inversão de prioridade.
No FreeRTOS, essa distinção é explícita. Um mutex é criado usando xSemaphoreCreateMutex() ou xSemaphoreCreateRecursiveMutex(), mas internamente ele é tratado de forma diferente de um semáforo binário criado com xSemaphoreCreateBinary(). Embora ambos possam assumir apenas os estados “disponível” ou “indisponível”, apenas o mutex ativa o mecanismo de herança de prioridade. Usar um semáforo binário para proteger um recurso compartilhado entre tarefas de diferentes prioridades é um erro de projeto clássico — e extremamente comum.
Outro ponto conceitual importante é o tempo de posse. Mutexes devem ser mantidos pelo menor tempo possível, protegendo apenas a seção crítica estritamente necessária. Já semáforos podem representar eventos acumulativos, filas de recursos ou até contadores de tarefas pendentes. Essa diferença afeta diretamente o comportamento temporal do sistema, especialmente quando o escalonador do FreeRTOS precisa decidir qual tarefa executar a seguir.
Finalmente, há uma restrição prática que reforça essa separação de papéis: mutexes não podem ser usados em ISRs no FreeRTOS. Como o conceito de herança de prioridade depende do contexto de tarefa, permitir o uso de mutexes em interrupções quebraria as garantias do kernel. Semáforos, por sua vez, possuem APIs específicas para uso em ISR, como xSemaphoreGiveFromISR(), o que os torna a escolha correta para esse cenário.
Com essas bases conceituais estabelecidas, estamos prontos para analisar quais tipos de mutex o FreeRTOS implementa, quais problemas cada um resolve e como eles se comportam internamente.