O que é e como funciona na prática
Doador de memorias é basicamente um software ou prática que permite compartilhar memória RAM entre processos, máquinas virtuais ou até entre computadores em rede. No Brasil, o termo aparece com mais frequência em contextos de virtualização, otimização de servidores e, às vezes, em comunidades de entusiastas que montam configurações customizadas de hardware. O funcionamento varia conforme a ferramenta, mas a ideia central é a mesma: alocar um bloco de memória em um processo e permitir que outro o acesse sem precisar fazer cópias. Isso economiza recursos, claro, mas traz complexidade. Gerenciar acesso concorrente exige cuidado. Se dois processos escrevem no mesmo bloco ao mesmo tempo, você tem corrupção de dados. Por isso, a maioria das soluções sérias implementa algum tipo de sincronização, seja via mutex, memória compartilhada com flags de leitura/escrita, ou mecanismos de cópia sob demanda (copy-on-write).
doador de memorias — o que você precisa saber antes de usar
Antes de baixar qualquer ferramenta genérica pelo Google, entenda o que exatamente você precisa. Doador de memorias não é um produto único. Existem bibliotecas como SHM (shared memory) no Linux, Named Shared Memory no Windows, bibliotecas Python como multiprocessing.shared_memory, e soluções mais avançadas como GPUDirect para acesso direto a memória de GPU. Cada uma serve para um contexto diferente. Se você está num ambiente Linux e quer compartilhar memória entre containers ou processos leves, IPC tradicional com System V shared memory ou POSIX shm pode ser suficiente. Se o objetivo é passed memory between VMs, aí entra SR-IOV ou virtio-mmio. No Windows, CreateFileMapping com nome é o caminho mais direto.
Tive um caso específico recently onde precisava compartilhar um buffer de 2GB entre um processo de captura de vídeo e um processo de inferência de ML. Usei shm_open com mmap no Linux. O problema foi que o buffer era alocado com O_TMPFILE e, ao reiniciar o processo leitor, o arquivo temporário já tinha sido descartado e o mmap falhava silenciosamente com ENOENT. A solução foi usar um nome fixo persistente em /dev/shm/ em vez de temporário. Levei uns 40 minutos até entender o que estava acontecendo, porque o erro não era evidente nos logs. Só percebi quando rodei um ls -la /dev/shm/ e vi que o arquivo sumira entre execuções.
Configuração passo a passo — cenário comum no Linux
Vamos pegar o caso mais frequente: compartilhar memória entre dois processos Python num servidor Linux. Isso resolve a maior parte dos problemas que vejo em fóruns e listservs. Primeiro, verifique se seu kernel suporta devtmpfs. Na maioria das distributions modernas, /dev/shm já está montado por padrão. Roda um df -h /dev/shm para confirmar. Se não estiver, monte com mount -t tmpfs tmpfs /dev/shm.
Agora o código. O processo writer cria o segment:
from multiprocessing import shared_memory
shm = shared_memory.SharedMemory(name='meu_bloco', create=True, size=1048576)
shm.buf[:100] = bytes(range(100))
👉 Clique no botão abaixo para saber mais sobre o assunto!
O processo reader conecta no mesmo segmento:
from multiprocessing import shared_memory
shm = shared_memory.SharedMemory(name='meu_bloco')
data = bytearray(shm.buf[:100])
Quando terminar, o writer deve liberar: shm.close(); shm.unlink(). Se você pular o unlink, o segmento persiste no sistema e vaza memória. Já vi servidores de produção com dezenas de segmentos órfãos consumindo gigabytes porque o processo que os criou morreu antes de fazer a limpeza.
Armadilhas comuns e como evitá-las
Um dos erros mais frequentes é assumir que shared memory é sinônimo de sincronização automática. Ela não é. Dois processos podendo escrever simultaneamente no mesmo endereço é uma corrida garantida. Use barreiras de memória, semaforos ou pelo menos um protocolo de produtor-consumidor com flags. No meu caso de inferência, resolvi com um par de semáforos POSIX:
import ctypes
sem = ctypes.CDLL('libc.so.6').sem_open(b'sem_foo', 0, 0o644, 1)
Outro erro é confundir o tamanho do segmento com a capacidade do /dev/shm. Se seu servidor tem 16GB de RAM mas o /dev/shm foi montado com opção size=2g, você não vai conseguir alocar 4GB lá dentro. Verifique com mount | grep shm e ajuste se necessário. Em containers Docker, o /dev/shm por padrão é limitado a 64MB, o que quebra qualquer tentativa séria de shared memory. A correção é passar --shm-size=2g na criação do container.
Quando não usar
Memória compartilhada não é bala de prata. Ela introduz acoplamento forte entre processos. Se um processo crasha escrevendo em área errada, outro pode corromper dados sem. Para sistemas distribuídos realmente, onde processos rodam em máquinas diferentes, shared memory local não funciona. Aí o caminho é RPC, MessagePack, gRPC ou filas de mensagem como Redis ou ZeroMQ. Também não recomendo para dados sensíveis. Memória compartilhada fica acessível no /dev/shm e qualquer processo com permissão de leitura do nome do segmento pode acessar o conteúdo. Se você precisa de privacidade, use criptografia no nível da aplicação ou memória encriptada (eDMA), que é outra história.
Alternativas
Se shared memory está causando mais dor de cabeça do que benefício, considere zeromq com buffers de memória, ou bibliotecas como Crossbar.io para comunicação entre processos. Para transferência de arquivos grandes entre máquinas, rsync e NFS são mais confiáveis do que tentar forçar shared memory através de rede. O ponto principal é: entenda o problema antes de escolher a ferramenta. Doador de memorias é um conceito, não um produto. A implementação certa depende do que você está tentando fazer, de quantos processos estão envolvidos e de qual sistema operacional está rodando. Teste em ambiente controlado antes de colocar em produção. Um erro de sincronização em shared memory pode ser muito mais difícil de diagnosticar do que um deadlock simples em threads convencionais, porque não há stack trace claro — o dado simplesmente chega corrompido.
