Почему бы не использовать boost :: mutex в общей памяти по сравнению с boost :: interprocess_mutex?

Question

Имея в настоящее время на некоторое время было изучение и использование повысить общую память в гневе я прибыл в ментальной модели, когда следует использовать какой тип мьютекса, который выглядит следующим образом:

class IntendedToResideInProcessMemory { 
    boost::mutex mutex_for_this_process; // 1 
    boost::interprocess::interprocess_mutex 
     ok_but_pointless_to_use_interprocess_mutex_here; // 2 
} 

class IntendedToBeCreatedInSharedMemory { 
    boost::mutex bad_mutex_at_a_guess_this_will_allocate_something_on_heap;// 3 
    boost::interprocess::interprocess_mutex 
     good_for_multiprocess_shared_lock; // 4 
} 

Я надеюсь, что убежище В принципе это неправильно, поэтому, пожалуйста, поправьте меня, если да. Я намерен двигаться вперед и исправлять существующий код, а также свой собственный, который не соответствует этой картине, но я хочу быть уверенным.

Две части этого вопроса: Я предполагаю, что это действительно нормально, но бессмысленно использовать // 2 - в контексте это менее полезно, чем // 1, но каковы причины этого? Представление?

Для // 3, это мое предположение правильно? Может ли кто-нибудь дать техническую закулисную причину, почему она не будет работать или, по крайней мере, в каких обстоятельствах это не сработает?

Answer 1

Что касается пункта 3: ваш boost::mutex не будет виден вашему другому процессу. Мьютекс interprocess использует глобально названный объект системы, к которому можно получить доступ другим процессом, afaik, boost::mutex - нет.

Ваш boost::mutex, созданный в общей памяти, может в Windows, например, иметь HANDLE к объекту Mutex Windows, который будет выделен на вашей куче процесса. Эта куча не видна другим процессам.

Если вы посмотрите на boost::mutex класса, он имеет этот typedef

typedef platform-specific-type native_handle_type;, которая зависит от платформы.

Другой пример: POSIX мьютексы идентифицируют по их адресу, который отличается от процессов Благодаря @DeadMG для этого примера :)