связь между процессами с результатами совместно используемой памяти - PullRequest
Новая
       37

связь между процессами с результатами совместно используемой памяти

9 голосов
/ 27 февраля 2011

Я пишу сетевой демон в Linux с ядром 2.6, в котором один процесс производителя и N пользовательских процессов , которые не вносят никаких изменений в данные, ине создает никакого ответа обратно производителю.

Всякий раз, когда процесс производителя создает объект данных, длина которого варьируется от нескольких 10 байтов до нескольких 10 Кбайт, он должен передать объект данных в одинДоступный потребительский процесс.

Впервые я решил использовать именованную / неназванную ТРУБУ.Тем не менее, это может привести к накладным расходам при копировании памяти.

  1. буфер пользовательского пространства производителя --copy -> буфер PIPE пространства ядра
  2. буфер PIPE пространства ядра --copy--> пользовательский буфер пользовательского пространства

Поскольку программа может работать с большим количеством пиров с низкой задержкой, накладные расходы на копирование могут быть вредными.Таким образом, я решил использовать совместно используемую память POSIX с mmap ().

Мне просто интересно, не приводит ли совместное использование данных между процессами, использующими Совместно используемая память POSIX с mmap (), копия памяти , в отличие от ТРУБЫ.

Кроме того, есть ли другой способ обмена данными между процессами, но результаты без копирования?Программа будет работать в Linux с последней версией ядра и может не иметь кроссплатформенной способности.

Я решил не создавать / запускать потоки для каждого потребителя / продукта, но из-за процессак вопросам проектирования.

Спасибо за ответ.

Ответы [ 3 ]

5 голосов
/ 27 февраля 2011

Общая память в целом разработана специально, чтобы не вызывать издержек при копировании (источник: http://www.boost.org/doc/libs/1_46_0/doc/html/interprocess/sharedmemorybetweenprocesses.html#interprocess.sharedmemorybetweenprocesses.sharedmemory.shared_memory_what_is).

Если вы используете C ++, Boost :: Interprocess - отличная библиотека для реализации того, что вы описываете, кросс-платформенным способом - вы можете использовать их класс совместно используемой памяти в сочетании с named_upgradable_mutex. Класс named_upgradable_mutex поддерживает предоставление эксклюзивных и разделяемых блокировок ресурса, поэтому вы можете легко реализовать с его помощью модель «потребитель-производитель». (источник: http://www.boost.org/doc/libs/1_37_0/doc/html/boost/interprocess/named_upgradable_mutex.html#id2913393-bb)

2 голосов
/ 27 февраля 2011

Совместно используемая память не должна вводить никаких копий (за исключением когерентности кэша), и вы можете напрямую обращаться к памяти, чтобы вы могли избежать копий в своем коде.

0 голосов
/ 27 февраля 2011

Да, это должна быть нулевая копия.

Тем не менее, это также (возможно, преждевременная) оптимизация, и вам необходимо приложить немало усилий, чтобы убедиться, что ваши процессы правильно взаимодействуют с распределением / освобождением / изменением общей памяти,Вам наверняка понадобится какой-нибудь мьютекс, чтобы избежать проблем одновременного доступа.

Лично я бы использовал каналы, пока производительность не станет надлежащей проблемой.Если это действительно так, то предложение использовать Boost :: Interprocess или аналогичную библиотеку является разумным.

...