Именованный мьютекс умершего приложения

new_life · 06.07.2018, 20:21. **Показов** 1503. **Ответов** 5

Студворк — интернет-сервис помощи студентам

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

Какой самый популярный вариант обхода таких ситуаций? Спасибо.

@Mikhail1990 · 07.07.2018, 15:37

new_life, крайне плохо соображаю как работать с синхронизацией. Но возможно можно сделать процесс наблюдатель который бы следил за состоянием мьютекса?

@TRam_ · 07.07.2018, 17:44

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

new_life · 09.07.2018, 11:19 **[ТС]**

Сообщение от Mikhail1990

Но возможно можно сделать процесс наблюдатель который бы следил за состоянием мьютекса?

Мммм, этого делать нельзя

программа есть программа. Когда она не запущена, ничего не должно у пользователя лишнего висеть.

Сообщение от TRam_

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

Да, наверное, что-то надо делать с процессами. Но что, пока не понятно, чтобы не было криво. Если мы просто будем искать процессы, то может возникнуть такая ситуация:
1. Пользователь запускает наше приложение (несколько экземпляров).
2. Программа проверила, увидела, что есть другие процессы, создала мьютекс, взяла его.
3. Другие процессы нашли другие процессы, открыли мьютекс и висят на нем, ждут, когда экземпляр из шага 2 освободит его.
3. Пользователь жмет кнопку reset. Мьютекс остается во взятом состоянии.
4. Пользователь снова запускает приложение, оно видит, что есть другие процессы и есть мьютекс. Оно открывает мьютекс и блокируется на нем, так как не знает, что разлочить этот мьютекс будет некому.

@Human_foot · 09.07.2018, 12:48

Нет, так не надо. У мьютексов есть хозяин, но если хозяин умирает (аварийное завершение, перезагрузка или просто забыли освободить мьютекс), то при попытке доступа к мьютексу получаем wait_abandoned.
Другими словами, если при запуске нового процесса получаем wait_abandoned, то нужно удалить файл (руками или через освобождение) и создать мьютекс.
https://www.boost.org/doc/libs... ersistence

new_life · 09.07.2018, 16:03 **[ТС]**

Сообщение от Human_foot

то при попытке доступа к мьютексу получаем wait_abandoned

Под wait_abandoned имеется в виду исключение? Но такого точно не происходит под линуксом. Как я быстро почитал по документациям, такой стейт выставляется только под виндой.

Добавлено через 2 часа 27 минут
Human_foot, благодарю за ссылку, там хорошая табличка. Persistence у file lock'а - процесс и, похоже, что все работает, как мне нужно. Переработка кода на файловые локи получилась небольшая.

Новые блоги и статьи Все статьи Все блоги /
Кто-нибудь знает, где можно бесплатно получить настольный компьютер или ноутбук? США. Programma_Boinc 26.12.2025 Кто-нибудь знает, где можно бесплатно получить настольный компьютер или ноутбук? США. Нашел на реддите интересную статью под названием «Кто-нибудь знает, где получить бесплатный компьютер или. . .	Thinkpad X220 Tablet — это лучший бюджетный ноутбук для учёбы, точка. Programma_Boinc 23.12.2025 Рецензия / Мнение/ Перевод Нашел на реддите интересную статью под названием The Thinkpad X220 Tablet is the best budget school laptop period . Ниже её машинный перевод. Thinkpad X220 Tablet —. . .	PhpStorm 2025.3: WSL Terminal всегда стартует в ~ and_y87 14.12.2025 PhpStorm 2025. 3: WSL Terminal всегда стартует в ~ (home), игнорируя директорию проекта Симптом: После обновления до PhpStorm 2025. 3 встроенный терминал WSL открывается в домашней директории. . .	Как объединить две одинаковые БД Access с разными данными VikBal 11.12.2025 Помогите пожалуйста !! Как объединить 2 одинаковые БД Access с разными данными.	Новый ноутбук volvo 07.12.2025 Всем привет. По скидке в "черную пятницу" взял себе новый ноутбук Lenovo ThinkBook 16 G7 на Амазоне: Ryzen 5 7533HS 64 Gb DDR5 1Tb NVMe 16" Full HD Display Win11 Pro
Музыка, написанная Искусственным Интеллектом volvo 04.12.2025 Всем привет. Некоторое время назад меня заинтересовало, что уже умеет ИИ в плане написания музыки для песен, и, собственно, исполнения этих самых песен. Стихов у нас много, уже вышли 4 книги, еще 3. . .	От async/await к виртуальным потокам в Python IndentationError 23.11.2025 Армин Ронахер поставил под сомнение async/ await. Создатель Flask заявляет: цветные функции - провал, виртуальные потоки - решение. Не threading-динозавры, а новое поколение лёгких потоков. Откат?. . .	Поиск "дружественных имён" СОМ портов Argus19 22.11.2025 Поиск "дружественных имён" СОМ портов На странице: https:/ / norseev. ru/ 2018/ 01/ 04/ comportlist_windows/ нашёл схожую тему. Там приведён код на С++, который показывает только имена СОМ портов, типа,. . .	Сколько Государство потратило денег на меня, обеспечивая инсулином. Programma_Boinc 20.11.2025 Сколько Государство потратило денег на меня, обеспечивая инсулином. Вот решила сделать интересный приблизительный подсчет, сколько государство потратило на меня денег на покупку инсулинов. . . .	Ломающие изменения в C#.NStar Alpha Etyuhibosecyu 20.11.2025 Уже можно не только тестировать, но и пользоваться C#. NStar - писать оконные приложения, содержащие надписи, кнопки, текстовые поля и даже изображения, например, моя игра "Три в ряд" написана на этом. . .

new_life Заблокирован

	Именованный мьютекс умершего приложения 06.07.2018, 20:21. Показов 1503. Ответов 5 Метки нет (Все метки) Бустовые именованные мьютексы реализованы на винде через файлы, на линкусе через shared memory (грубо, тоже файлы). Проблема возникает, когда приложение использующее такой мьютекс умирает по внешней причине, файл мьютекса остается в файловой системе. При следующем запуске программы процесс открывает существующий мьютекс и подвисает, считая, что кто-то залочил этот мьютекс (так как он остался в таком стейте). Просто удалять файл мьютекса по имени сразу на старте до лока нельзя, так как, это может быть "живой" мьютекс от другого процесса, и мы должны на нем залочиться. Но если этот мьютекс остался от мертвого процесса, то потом его никто не разлочит. Процессы друг с другом не общаются, поэтому сообщить друг другу какую-то инфу вроде имени мьютекса не могут. То есть, им заранее просто известно имя мьютекса и дальше только синхронизация. Какой самый популярный вариант обхода таких ситуаций? Спасибо. 0

@Mikhail1990 27 / 26 / 6 Регистрация: 22.03.2014 Сообщений: 277
	07.07.2018, 15:37
	new_life, крайне плохо соображаю как работать с синхронизацией. Но возможно можно сделать процесс наблюдатель который бы следил за состоянием мьютекса? 0

@TRam_ зомбяк 1585 / 1219 / 345 Регистрация: 14.05.2017 Сообщений: 3,940
	07.07.2018, 17:44
	Вероятно, нужно искать прочие запущенные в системе процессы, и только при их нахождении проверять мьютекс. 0

@Human_foot 156 / 108 / 36 Регистрация: 27.06.2018 Сообщений: 256
	09.07.2018, 12:48
	Нет, так не надо. У мьютексов есть хозяин, но если хозяин умирает (аварийное завершение, перезагрузка или просто забыли освободить мьютекс), то при попытке доступа к мьютексу получаем wait_abandoned. Другими словами, если при запуске нового процесса получаем wait_abandoned, то нужно удалить файл (руками или через освобождение) и создать мьютекс. https://www.boost.org/doc/libs... ersistence 1