boost :: interprocess_mutex против процесса локального boost :: mutex
Я работаю над проектом, который использует boost::interprocess_mutexЭто повсеместно, хотя приложение никогда даже fork()s дети, но сильно зависит от многопоточности.
Правильно ли предположить, что все эти interprocess_mutexМожно ли заменить процесс локальными мьютексами, ничего не нарушая?
Правильно ли мое предположение, что это может повысить производительность (хотя бы с минимальным коэффициентом)?
Есть ли какая-либо мыслимая причина для использования межпроцессной синхронизации в рамках одного (необязательно многопоточного) процесса?
Решение
Использует ли он общую память или какой-то другой механизм IPC? и эта память используется несколькими приложениями? Это тест …
Он не должен быть разветвленным, могут быть разные базы кода (отдельные исполняемые файлы), разделяющие некоторый ресурс. Например, есть ли приложение для мониторинга или интерфейс, который получает статистику от приложения, поскольку оно работает через какой-то механизм IPC? Обратите внимание, что могут быть и другие лучшие способы сделать это, это всего лишь пример.
Глядя на заголовки:
http://www.boost.org/doc/libs/1_52_0/boost/interprocess/sync/windows/mutex.hpp
http://www.boost.org/doc/libs/1_52_0/boost/interprocess/sync/posix/mutex.hpp
Это накладные расходы, и замена их на локальную версию (If Safe) может принести вам некоторую эффективность. Однако я не слишком знаком с реализацией Posix.
Как я уже говорил выше, вы можете использовать IPC, если внешнее приложение использует, скажем, разделяемую память, для получения статистики или обмена данными — но если это не так, то вы, вероятно, можете заменить их.
Другие решения
Других решений пока нет …
detector