Modelos clássicos de múltiplos consumidores e o impacto no escalonador
Quando várias tarefas consumidoras bloqueiam na mesma Queue, o comportamento observado em tempo de execução é consequência direta de como o FreeRTOS gerencia listas de tarefas bloqueadas e do seu modelo de escalonamento por prioridade. Entender esse mecanismo é essencial para evitar efeitos colaterais como starvation, inversão lógica de carga e consumo desigual de mensagens.
Internamente, cada Queue mantém duas listas principais: uma de tarefas bloqueadas esperando espaço para escrita (tasks waiting to send) e outra de tarefas bloqueadas esperando dados (tasks waiting to receive). No caso de múltiplos consumidores, todas as tarefas que chamam xQueueReceive() com tempo de bloqueio diferente de zero entram na mesma lista de espera. Quando um item é inserido na fila, apenas uma tarefa é removida dessa lista e desbloqueada, nunca todas.
A regra de desempate segue um critério simples, porém poderoso: a tarefa de maior prioridade pronta para executar será a escolhida. Se houver várias tarefas com a mesma prioridade, entra em cena o time slicing, caso esteja habilitado (configUSE_TIME_SLICING). Isso significa que, na prática, consumidores de maior prioridade tendem a monopolizar a fila, mesmo que existam outros consumidores funcionais e corretamente bloqueados.
Esse comportamento é desejável em arquiteturas do tipo worker pool, onde consumidores de maior prioridade representam tarefas mais críticas ou com deadlines mais rígidos. Um exemplo típico é um sistema de comunicação, onde pacotes de controle precisam ser processados antes de pacotes de telemetria. Entretanto, se todas as tarefas consumidoras possuem a mesma função lógica, mas prioridades diferentes por descuido de projeto, o sistema pode apresentar starvation silenciosa, em que uma ou mais tarefas praticamente nunca recebem dados.
Observe o exemplo abaixo:
xTaskCreate(vConsumerTask, "ConsumerHigh", 512, NULL, 3, NULL);
xTaskCreate(vConsumerTask, "ConsumerLow", 512, NULL, 1, NULL);
Mesmo que ambas executem exatamente o mesmo código, a tarefa de prioridade 3 receberá quase todas as mensagens, enquanto a de prioridade 1 só será desbloqueada quando a de maior prioridade estiver bloqueada por outro motivo. Isso não é um bug do FreeRTOS, mas uma consequência direta de seu modelo determinístico de escalonamento.
Outro ponto crítico é o tempo de processamento dentro do consumidor. Se uma tarefa consome a mensagem e executa uma rotina longa antes de voltar a bloquear na fila, ela reduz a chance de outras tarefas competirem pelos próximos itens. Esse padrão cria um efeito de captura, onde um único consumidor domina a fila simplesmente porque retorna mais rápido ao estado bloqueado. Em sistemas com processamento pesado, isso pode ser mitigado com divisão explícita de tarefas ou uso de filas intermediárias.
Um modelo bastante utilizado para reduzir esse efeito é separar recepção e processamento, conforme o exemplo:
void vConsumerTask(void *pvParameters)
{
message_t msg;
for (;;)
{
if (xQueueReceive(xQueue, &msg, portMAX_DELAY) == pdPASS)
{
xQueueSend(xProcessingQueue, &msg, portMAX_DELAY);
}
}
}
Aqui, a fila original atua apenas como ponto de sincronização rápido, enquanto o processamento pesado ocorre em outro estágio do pipeline. Esse padrão melhora o balanceamento entre consumidores e reduz o acoplamento entre tempo de execução e política de escalonamento.
Em resumo, usar Queue com múltiplos consumidores é arquiteturalmente correto quando os consumidores competem por trabalho, e não quando precisam observar os mesmos eventos. O projetista deve considerar cuidadosamente prioridades relativas, tempo de processamento, e taxa de chegada de mensagens, pois esses fatores determinam diretamente quem consome o quê — e com que frequência.
Na próxima seção, vamos tratar dos principais cuidados e armadilhas práticas, incluindo perda de eventos, starvation, bloqueios excessivos e como diagnosticar esses problemas em sistemas reais com FreeRTOS.
