Я бы использовал mmap
вместе с shm_open
для сопоставления разделяемой памяти с виртуальным адресным пространством процессов.Это относительно прямолинейно и чисто:
- вы идентифицируете свой сегмент совместно используемой памяти с каким-то символическим именем, что-то вроде
"/myRegion"
- с
shm_open
, вы открываете дескриптор файлав этом регионе - с помощью
ftruncate
вы увеличиваете сегмент до нужного вам размера - с помощью
mmap
вы отображаете его в свое адресное пространство
* 1019Интерфейсы * и Co имеют (по крайней мере исторически) тот недостаток, что они могут иметь ограничение в максимальном объеме памяти, который вы можете отобразить.
Затем все инструменты синхронизации потоков POSIX (pthread_mutex_t
, * 1023)*, sem_t
, pthread_rwlock_t
, ...) имеют интерфейсы инициализации, которые позволяют использовать их также в общем контексте процесса.Все современные дистрибутивы Linux поддерживают это.
Является ли это предпочтительнее, чем сокеты?С точки зрения производительности это может иметь значение, поскольку вам не нужно копировать вещи.Но основной момент, который я предполагаю, состоит в том, что, как только вы инициализируете свой сегмент, концептуально это будет немного проще.Чтобы получить доступ к элементу, вам просто нужно взять блокировку на общей блокировке, прочитать данные, а затем снова разблокировать блокировку.
Как подсказывает @R, если у вас несколько считывателей, pthread_rwlock_t
, вероятно,Лучшая структура замка для использования.