Кратко и по делу — сравнение pipe (анонимный/именованный), socketpair (AF_UNIX), shared memory (shm, mmap) и message queue (POSIX / System V) по четырём критериям, с пояснениями и практическими примерами.
Общие упрощённые ранжирования (где “>” — лучше по скорости/меньше задержка/проще синхр. и т.п.):
- Пропускная способность: $\text{shm}>\text{socketpair}\approx \text{pipe}>\text{mqueue}$.
- Задержка (latency): $\text{shm}<\text{socketpair}\approx \text{pipe}<\text{mqueue}$.
- Сложность синхронизации (меньше = проще): $\text{pipe}/\text{socketpair}/\text{mqueue}<\text{shm}$.
- Безопасность (по умолчанию, изолированность и контроль доступа): нет универсального порядка — зависит от прав/контекста; приблизительно: $\text{socketpair}\gtrsim \text{mqueue}\gtrsim \text{pipe}>\text{shm}$ (shared memory требует дополнительных мер).
Почему так:
1) Пропускная способность
- Shared memory: даёт наибольшую пропускную способность, потому что данные не копируются через ядро при чтении/записи (процесс просто пишет в RAM). Практический предел — пропускная способность памяти/кэш/шина.
- Pipe / socketpair (unix domain): данные обычно проходят через ядро и копируются между буфером ядра и буферами процессов → копии и syscalls ограничивают скорость. UNIX domain sockets иногда оптимизированы (минимизация копий), но всё равно уступают SHM для больших объёмов.
- Message queue: каждый message обычно копируется и управляется ядром; накладные расходы на заголовки, приоритеты, лимиты уменьшают пропускную способность.
2) Задержка
- SHM минимальна, если синхронизация (замки, атомики) оптимизирована.
- Pipe/socketpair близки по latency (syscall + копирование). Для небольших сообщений задержка сравнима.
- Message queue — выше из‑за управления очередью и дополнительных проверок; для очень частых мелких сообщений может быть ощутимо хуже.
3) Сложность синхронизации
- Pipe/socketpair/message queue: kernel обеспечивает очередность и атомарность сообщений (для записей ≤ $PIPE\_BUF$ запись в pipe атомарна — POSIX гарантирует минимум $512$ байт; в Linux обычно $PIPE\_BUF=4096$), поэтому программисту не нужен явный mutex для целостности сообщений.
- Message queue даёт дополнительно приоритеты и атомарность сообщений, но управляет только пакетами.
- Shared memory: необходимость явной синхронизации (futex, pthread mutex в разделяемой памяти, семафоры). Неправильные барьеры/порядок записей приведут к гонкам и subtle багам. Но при правильно реализованной синхронизации достигается очень высокая производительность.
4) Безопасность и контроль доступа
- Socketpair (AF_UNIX): локаль, можно получить учётные данные с помощью SO_PEERCRED, передавать файловые дескрипторы — гибкий и относительно безопасный (контроль через права файловой системы, возможность авторизации).
- Message queues и named pipes (FIFO): имеют права доступа (chmod/uid/gid), но модель простая.
- Anonymous pipe: работает между родственниками (fork), изолирован по конвенциям, но не имеет сложной аутентификации.
- Shared memory (shm_open / SysV shmget): сегменты видимы в пространстве имен, права существуют, но утечка содержимого (необнулённая память), отсутствие явного обмена учётными данными и необходимость синхронизации повышают риск (особенно для секретных данных нужно mlock/zeroize). Требует осторожности с правами и очисткой.
Дополнительные особенности (важные при выборе)
- Передача FD: unix domain sockets поддерживают передачу файловых дескрипторов (SCM_RIGHTS) — уникальное свойство, полезно при делегировании ресурсов.
- Полосы в kernel: pipe/socketpair/mqueue используют ядро для буферизации; это упрощает модель producer/consumer (блокирующие/неблокирующие, select/poll/epoll поддерживаются для pipe/socket).
- Оповещения: mq_notify (POSIX) позволяет уведомлять через сигнал/сигнэл или реентераблный fd; для SHM нужно отдельный механизм (eventfd, futex, semaphores).
- Устойчивость: System V message queues могут переживать процессы до удаления; POSIX mq и shm объекты тоже существуют в ядре до unlink.
Практические рекомендации / когда что предпочтительнее
- Shared memory (shm/mmap)
- Когда: передача больших объёмов данных (видео, аудио, картины) с минимальными накладными расходами; требуются высокая пропускная способность и низкая задержка.
- Нюансы: нужен надёжный механизм синхронизации (futex, pthread mutex в SHM, барьеры). Уделите внимание безопасности (права, очистка).
- Pipe (anonymous/ named FIFO)
- Когда: простой однонаправленный поток данных между родительским и дочерним процессом (stdout|stdin перенаправления), простая конвейерная обработка.
- Плюсы: простота, POSIX-гарантия атомарности мелких записей (≤ $PIPE\_BUF$).
- Минусы: не подходит для произвольного двунаправленного обмена (хотя можно создать пару), неэффективен для больших блоков данных по сравнению с SHM.
- Socketpair / UNIX domain socket
- Когда: нужен двунаправленный обмен, поддержка select/poll/epoll, передача FD, или аутентификация локального клиента (SO_PEERCRED). Подходит для RPC между компонентами на одной машине.
- Плюсы: гибкость, можно установить блокирующие/неблокирующие, передачи дескрипторов, хорошо интегрируется с сетевыми интерфейсами (одинаковая модель).
- Минусы: чуть хуже по throughput по сравнению с SHM для больших буферов.
- Message queue (POSIX / SysV)
- Когда: асинхронная маршрутизация сообщений, приоритизация сообщений, декуплинг производителей и потребителей, когда нужны kernel‑буферы и сохранение пока потребитель не прочитал.
- Плюсы: простая семантика сообщений, приоритеты, нативная очередность, уведомления.
- Минусы: ограничения на размер и количество сообщений (параметры), более низкая throughput при больших объёмах маленьких сообщений.
Короткие примеры
- Видеообработка в реальном времени между процессами на одной машине: SHM + futex/eventfd для синхронизации.
- Простая конвейерная обработка (grep | sort): anonymous pipes.
- Демон и его рабочие процессы, которые должны обмениваться командной/результатной информацией и file descriptors: unix socketpair (передача FD + SO_PEERCRED).
- Очередь задач с приоритетами и непредсказуемыми пиками: POSIX message queue или брокер (mq) — потому что kernel буферизует и упорядочивает по сообщениям.
Краткий вывод
- Для максимальной пропускной способности/минимальной задержки — shared memory + аккуратная синхронизация.
- Для простоты протокола и атомарности сообщений — pipe/socketpair/mqueue (в зависимости от требований: fd passing, приоритеты, именованность).
- Для безопасности и контроля доступа — unix domain sockets и внимательная настройка прав для shm/mqueue.
Если нужно — могу привести конкретные шаблоны кода (пример использования futex в SHM, пример передачи FD через unix socket, или шаблон использования POSIX mq).