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

new_life · 06.07.2018, 20:21. **Показов** 1549. **Ответов** 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'а - процесс и, похоже, что все работает, как мне нужно. Переработка кода на файловые локи получилась небольшая.

Новые блоги и статьи Все статьи Все блоги /
SDL3 для Desktop (MinGW): Создаём пустое окно с нуля для 2D-графики на SDL3, Си и C++ 8Observer8 10.03.2026 Содержание блога Финальные проекты на Си и на C++: hello-sdl3-c. zip hello-sdl3-cpp. zip Результат:	Установка CMake и MinGW 13.1 для сборки С и C++ приложений из консоли и из Qt Creator в EXE 8Observer8 10.03.2026 Содержание блога MinGW - это коллекция инструментов для сборки приложений в EXE. CMake - это система сборки приложений. Здесь описаны базовые шаги для старта программирования с помощью CMake и. . .	Как дизайн сайта влияет на конверсию: 7 решений, которые реально повышают заявки Neotwalker 08.03.2026 Многие до сих пор воспринимают дизайн сайта как “красивую оболочку”. На практике всё иначе: дизайн напрямую влияет на то, оставит человек заявку или уйдёт через несколько секунд. Даже если у вас. . .	Модульная разработка через nuget packages DevAlt 07.03.2026 Сложившийся в . Net-среде способ разработки чаще всего предполагает монорепозиторий в котором находятся все исходники. При создании нового решения, мы просто добавляем нужные проекты и имеем. . .
Модульный подход на примере F# DevAlt 06.03.2026 В блоге дяди Боба наткнулся на такое определение: В этой книге («Подход, основанный на вариантах использования») Ивар утверждает, что архитектура программного обеспечения — это структуры,. . .	Управление камерой с помощью скрипта OrbitControls.js на Three.js: Вращение, зум и панорамирование 8Observer8 05.03.2026 Содержание блога Финальная демка в браузере работает на Desktop и мобильных браузерах. Итоговый код: orbit-controls-threejs-js. zip. Сканируйте QR-код на мобильном. Вращайте камеру одним пальцем,. . .	SDL3 для Web (WebAssembly): Синхронизация спрайтов SDL3 и тел Box2D 8Observer8 04.03.2026 Содержание блога Финальная демка в браузере. Итоговый код: finish-sync-physics-sprites-sdl3-c. zip На первой гифке отладочные линии отключены, а на второй включены:. . .	SDL3 для Web (WebAssembly): Идентификация объектов на Box2D v3 - использование userData и событий коллизий 8Observer8 02.03.2026 Содержание блога Финальная демка в браузере. Итоговый код: finish-collision-events-sdl3-c. zip Сканируйте QR-код на мобильном и вы увидите, что появится джойстик для управления главным героем. . . .

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

	Именованный мьютекс умершего приложения 06.07.2018, 20:21. Показов 1549. Ответов 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 / 114 / 36 Регистрация: 27.06.2018 Сообщений: 257
	09.07.2018, 12:48
	Нет, так не надо. У мьютексов есть хозяин, но если хозяин умирает (аварийное завершение, перезагрузка или просто забыли освободить мьютекс), то при попытке доступа к мьютексу получаем wait_abandoned. Другими словами, если при запуске нового процесса получаем wait_abandoned, то нужно удалить файл (руками или через освобождение) и создать мьютекс. https://www.boost.org/doc/libs... ersistence 1