Comments 10
Это решение потоко безопасно? Что будет если у меня два писателя?
Если речь про boost::unordered_map - нет. По умолчанию решение не потокобезопасно, но это решается через разделяемые мютексы, в boost есть boost::interprocess::named_mutex и др., кроме того аллокатор тоже не потокобезопасен и при конкуретнтном доступе может попортить память, так что нужно быть осторожным в этом плане.
На эту тему есть также информативная и обозримая (25 страниц) статья с множеством примеров: https://opensource.com/sites/default/files/gated-content/inter-process_communication_in_linux.pdf
Для начала мы определяем псевдонимы типов для работы со строками, мы определили ShmString как тип std::basic_string с аллокатором ShmCharAllocator, который выделяет память из сегмента shared memory. Это гарантирует, что и сам объект строки, и его внутренний буфер будут находиться в общей памяти.
А как там разруливается то, что в разных процессах shared memory может замапиться по разным виртуальным адресам?
Через boost::interprocess::offset_ptr
Разве аллокатор (того же std::basic_string) может подменить тип указателя?
Спасибо за замечание. Да, не может, необходим boost::interprocess::basic_string который работает с этим указателем. Поправил в статье.
Теперь понятно )
Да, посмотрел в boost::interprocess::offset_ptr - там используется оптимизированное представление
OffsetType m_offset; //Distance between this object and pointee address
Нюанс в том, что на него был патент - сходу найти не могу, но коллеги встревали, срок у него вышел только лет пять назад (так что сейчас проблем с использованием нет).
никак, такой код не будет работать
Эффективное межпроцессное взаимодействие с использованием IPC и Shared Memory