Filas de Mensagens e IPC Estruturada

• Definir uma fila de mensagens como uma sequência, gerenciada pelo kernel, de mensagens discretas e limitadas, em contraste com o fluxo de bytes indiferenciado de um pipe e com a região bruta e não mediada da memória compartilhada.
• Explicar o que "o kernel media todo acesso" recupera em comparação com a memória compartilhada, e o que custa em comparação com a velocidade sem cópia da memória compartilhada.
• Descrever a prioridade de mensagens e o recebimento seletivo como capacidades reais que uma fila de mensagens fornece e que nem um pipe nem a memória compartilhada bruta fornecem.
• Posicionar corretamente as filas de mensagens no espectro que este bloco construiu até agora: do mais rápido/menos seguro (memória compartilhada) ao mais lento/mais estruturado (filas de mensagens), com os pipes ocupando um ponto intermediário específico.

Este bloco já cobriu dois mecanismos de IPC situados em extremos opostos de um trade-off real: um pipe (mediado pelo kernel, mas um fluxo de bytes indiferenciado sem fronteiras de mensagem) e a memória compartilhada (extremamente rápida, mas com zero estrutura ou sincronização embutidas, deixando aos processos cooperantes a tarefa de construir as duas coisas por conta própria). As filas de mensagens ocupam um terceiro ponto, distinto, nesse espectro: como num pipe, o kernel media cada acesso, mas, diferente de um pipe, o kernel trata cada transferência como uma mensagem discreta e autocontida em vez de uma sequência bruta de bytes; e, diferente tanto do pipe quanto da memória compartilhada, uma fila de mensagens real pode suportar prioridades de mensagem e recebimento seletivo, permitindo a um consumidor escolher qual mensagem em espera pegar em seguida em vez de ficar estritamente limitado à ordem first-in-first-out.

Entender as filas de mensagens completa o quadro real deste bloco sobre os trade-offs de fato que projetistas de sistemas enfrentam: velocidade versus segurança versus estrutura não vêm de graça. Todo mecanismo que este bloco cobre compra uma delas a algum custo para as outras, e nenhum mecanismo isolado domina os outros dois em todos os eixos.

Uma mensagem discreta versus um fluxo de bytes indiferenciado

Um pipe entrega bytes na exata ordem em que foram escritos, sem nenhuma noção de onde uma mensagem lógica termina e a próxima começa. Se um escritor realiza três chamadas write() separadas de 10 bytes cada, não há garantia de que um leitor receba três leituras separadas de 10 bytes; ele pode ver uma leitura de 30 bytes, ou dez leituras de 3 bytes, inteiramente à mercê de como o kernel calhou de bufferizar e entregar os bytes. Uma fila de mensagens remove essa ambiguidade inteiramente: cada operação equivalente a send enfileira uma mensagem completa e autocontida com um tamanho conhecido, e cada operação equivalente a receive desenfileira exatamente uma mensagem inteira, nunca um fragmento e nunca mais de uma mensagem fundidas. Esta é uma garantia estrutural real que um pipe simplesmente não fornece, e aplicações que precisam raciocinar sobre unidades discretas de trabalho (um job enfileirado, um evento registrado, uma requisição) se beneficiam diretamente de não precisar reimplementar elas mesmas o enquadramento de mensagens em cima de um fluxo de bytes bruto.

Mediação do kernel: segurança restaurada, velocidade devolvida

Como o kernel toca e gerencia cada mensagem da fila (alocando espaço para ela, rastreando quais mensagens estão pendentes, entregando-as a qualquer processo que peça para receber em seguida), as filas de mensagens restauram as duas coisas das quais a memória compartilhada abriu mão: ordem e bloqueio embutidos (uma chamada receive numa fila vazia bloqueia até que uma mensagem chegue, exatamente como o read de um pipe) sem necessidade de os dois processos cooperantes gerenciarem os seus próprios semáforos. O custo é simétrico ao benefício: cada send e receive é uma chamada de sistema real, e os bytes de fato da mensagem continuam sendo copiados (uma vez para dentro do armazenamento da fila do kernel, uma vez de volta para fora, para o processo receptor), o mesmo overhead por mensagem que um pipe paga, agora aplicado a mensagens estruturadas inteiras em vez de um fluxo bruto.

Prioridade e recebimento seletivo: capacidades que nem pipes nem memória compartilhada oferecem diretamente

A ordem FIFO estrita de um pipe significa que o primeiríssimo byte escrito é sempre o primeiríssimo byte que um leitor pode ver: não há forma de uma mensagem urgente, chegando depois, passar na frente de uma anterior, de menor prioridade, já enfileirada. APIs reais de filas de mensagens (as filas de mensagens POSIX, e as filas de mensagens do System V antes delas) suportam um valor de prioridade explícito anexado a cada mensagem, permitindo a um receptor obter primeiro a mensagem pendente de maior prioridade independentemente da ordem de chegada. Isso é genuinamente útil quando, por exemplo, uma mensagem de controle "aborte agora" precisa ser processada antes de um acúmulo de itens de trabalho comuns já enfileirados. Algumas APIs reais adicionalmente permitem a um receptor filtrar por uma tag de tipo de mensagem, obtendo só as mensagens que correspondem a um tipo específico e deixando as outras na fila para um consumidor diferente, uma forma de recebimento seletivo que nem um pipe (que não tem noção alguma de identidade de mensagem) nem a memória compartilhada bruta (que não tem noção alguma de fila) fornecem.

Onde as filas de mensagens ficam no espectro real de trade-offs deste bloco

Colocar os três mecanismos no mesmo eixo torna o trade-off concreto: a memória compartilhada é a mais rápida, mas não fornece estrutura nem sincronização próprias; um pipe é mediado pelo kernel (seguro, ordenado, bloqueante), mas só entrega um fluxo de bytes indiferenciado; uma fila de mensagens também é mediada pelo kernel, mas adicionalmente entrega mensagens discretas com prioridade e recebimento seletivo opcionais, ao custo de não ser mais rápida que um pipe, e na prática frequentemente um pouco mais lenta, devido à contabilidade adicional que o kernel realiza por mensagem.

Exemplo 1: A ambiguidade de fluxo de bytes de um pipe versus a entrega discreta de uma fila de mensagens

text
O escritor realiza três chamadas separadas:
  write(fd, "AAAAAAAAAA", 10);
  write(fd, "BBBBBBBBBB", 10);
  write(fd, "CCCCCCCCCC", 10);

Um leitor de pipe chamando read(fd, buf, 30) pode receber:
  "AAAAAAAAAABBBBBBBBBBCCCCCCCCCC"   -- todos os 30 bytes fundidos numa
                                          única leitura, sem forma de
                                          saber onde uma escrita terminou
                                          e a próxima começou.

Um receptor de fila de mensagens, usando send()/receive() em vez disso,
tem GARANTIDAS três chamadas receive() separadas, cada uma retornando
exatamente uma de "AAAAAAAAAA", "BBBBBBBBBB", "CCCCCCCCCC" -- nunca
fundidas, nunca divididas.

Exemplo 2: Entrega baseada em prioridade, concretamente

text
A fila recebe, nesta ordem de chegada:
  msg1 (prioridade 1, "processar job em lote")
  msg2 (prioridade 1, "processar job em lote")
  msg3 (prioridade 10, "ABORTAR TUDO")

Um mecanismo só FIFO (como um pipe) entregaria msg1, depois msg2,
depois msg3, nessa exata ordem de chegada.

Uma fila de mensagens com prioridade entrega msg3 PRIMEIRO, apesar
de ter chegado por último, porque a sua prioridade (10) excede a
prioridade de msg1 e msg2 (1) -- a mensagem de controle urgente
alcança o consumidor antes de qualquer job em lote enfileirado, sem
que o consumidor precise inspecionar e descartar ele mesmo mensagens
de menor prioridade.

Exemplo 3: Os três mecanismos de IPC até agora, comparados nos mesmos três eixos

text
Mecanismo             Mediado pelo kernel?  Estrutura de mensagem?  Velocidade relativa
--------------------  --------------------  ----------------------  -------------------
Pipe                  Sim                   Só fluxo de bytes       Moderada
Memória compartilhada Não (após config.)    Nenhuma (região bruta)  A mais rápida
Fila de mensagens     Sim                   Discreta + prioridade   Moderada/mais lenta

Nenhuma linha domina todas as colunas: cada mecanismo é um ponto genuinamente diferente no mesmo espaço de projeto, escolhido com base em qual propriedade (velocidade, estrutura ou segurança embutida) uma dada aplicação de fato mais precisa.

• "Uma fila de mensagens é só um pipe que calha de ser implementado de forma diferente." Um pipe garante só a ordem no nível de bytes, sem noção de fronteiras de mensagem; uma fila de mensagens garante que cada send corresponde a exatamente um receive, nunca fundido, nunca dividido, uma garantia estrutural que um pipe não faz.
• "Filas de mensagens são estritamente melhores que pipes, já que fazem tudo o que um pipe faz e mais." Elas custam mais por mensagem (contabilidade adicional do kernel para fronteiras de mensagem e, se usada, ordenação por prioridade) e não são significativamente mais rápidas. Para um caso de uso simples, de fluxo único e só FIFO, um pipe continua sendo a escolha mais simples e adequada.
• "Prioridade de mensagem significa que mensagens de maior prioridade são processadas mais rápido depois de recebidas." A prioridade só afeta a ORDEM em que as mensagens pendentes são entregues pelas chamadas receive(). Ela não diz nada sobre quão rápido o próprio processo receptor processa uma mensagem depois que a tem.
• "Filas de mensagens evitam o overhead de cópia que os pipes têm, já que são um mecanismo diferente." Elas ainda copiam os bytes de cada mensagem para o armazenamento do kernel e de volta para o receptor: o mesmo custo de cópia por mensagem que um pipe paga, agora aplicado a mensagens discretas em vez de um fluxo bruto, e não eliminado pela estrutura adicional.

Uma fila de mensagens é uma fila de mensagens discretas e limitadas, gerenciada e mediada pelo kernel, diferente de um pipe, que entrega um fluxo de bytes indiferenciado sem fronteiras de mensagem garantidas, e diferente da memória compartilhada, que não fornece estrutura nem sincronização alguma. Como o kernel toca cada mensagem, as filas de mensagens restauram automaticamente a ordem e o bloqueio, o mesmo benefício que um pipe já fornece, ao mesmo tempo em que suportam adicionalmente a entrega baseada em prioridade e o recebimento seletivo por tipo de mensagem, capacidades reais que nem um pipe nem a memória compartilhada bruta oferecem. O custo é que uma fila de mensagens não é mais rápida que um pipe, e na prática às vezes é mais lenta, devido à contabilidade adicional por mensagem que o kernel realiza para rastrear fronteiras e prioridade. Colocar os três mecanismos lado a lado torna explícita a lição real deste bloco: velocidade, segurança e estrutura se contrapõem umas às outras, e o mecanismo de IPC certo depende de qual das três uma dada aplicação genuinamente mais precisa.