Использование Mutex в разных процессах

Question

ОС: Windows Язык: C / C ++

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

Может ли быть лучшей идеей следующее?У меня есть идея назвать мьютекс в родительском процессе в качестве идентификатора процесса.Итак, теперь мне нужно получить идентификатор родительского процесса из дочернего процесса / великого дочернего процесса, чтобы открыть мьютекс.Я полагаю, что нет прямого способа получить идентификатор родительского процесса из процесса большого потомка.Поэтому мне нужно передавать идентификатор процесса в каждом API процесса создания (в lpenvironment parm).

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

Answer 1

Основная идея в порядке, но вы можете внести некоторые изменения в реализацию.

Например, если ваше приложение включает в себя взаимодействие нескольких процессов, то основной процесс «контроллера», который порождает подпроцессы, может легко передать свой PID через аргумент командной строки. Если подпроцессы также порождают своих собственных потомков, они могут передавать PID с помощью того же механизма.

Продолжая эту идею, вы также можете полностью пропустить PID и передать само имя мьютекса через аргумент командной строки дочерним процессам. Преимущество этого подхода заключается в том, что родительский и дочерний процессы не обязательно должны включать код, который получает имя мьютекса из PID. Передав само имя мьютекса, вы отделяете дочерние процессы от необходимости знать, как они создаются. Этот подход используется многими основными приложениями, например, Google Chrome.

И, наконец, вы можете добиться большего, добавив случайную строку (возможно, GUID?) К имени мьютекса. Я не верю, что кто-нибудь назовет свой собственный объект глобальной синхронизации с таким же именем, но некоторые дополнительные меры предосторожности не повредят.

Answer 2

Если я интерпретирую формулировку «процесс и его подпроцессы», а также «ребенок / внук», возникает ситуация, когда у вас есть один родительский процесс, который запускает одного или нескольких дочерних процессов (или , дети бери внуки). Или любая их комбинация, но в любом случае каждый процесс, о котором мы говорим, использует тот же мьютекс * , который создается родителем.

Если это предположение верно, почему бы просто не использовать что-то смущающее простое, как:

#define MUTEXNAME "MzdhYTYzYzc3Mzk4ZDk1NDQ3MzI2MmUxYTAwNTdjMWU2MzJlZGE3Nw"

Если вам интересно, откуда это пришло, я сгенерировал его с помощью одной строки:

php -r "echo substr(base64_encode(sha1('some text')), 0, -2);"

Замените «некоторый текст» своим именем, текущей датой или какими-либо случайными словами, которые у вас на уме в данный момент. Вероятность того, что любое другое приложение в вашей системе когда-либо будет иметь такое же имя мьютекса, практически равна нулю.

Answer 3

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

Это кажется действительным, но дескрипторы будут надежнее, чем PID, потому что PID могут быть переработаны. Метод использования дескрипторов (передача их дочерним процессам, аналогичный тому, который вы используете) обсуждается в этом потоке StackOverflow .

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

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