2011-12-14 1 views
0

Я использую boost::interprocess::named_upgradable_mutex для синхронизации нескольких процессов.interprocess :: named_upgradable_mutex - остается заблокированным, если процесс убит

Я использую boost::interprocess::sharable_lock и boost::interprocess::scoped_lock для блокировки мьютекса.

При тестировании синхронизации он выглядит нормально, пока процессы работают и нормально закрываются.

Но, я заметил, что если процесс убит (например, с помощью TaskManager), удерживая мьютекс, мьютекс остается заблокированным.

Любая идея, как я могу обрабатывать сбои процесса?

Я думал об использовании timed_lock() на всякий случай ... любые другие идеи?

+0

В каких обстоятельствах может быть убит процесс, чтобы весь экземпляр программы был убит? – curiousguy

+0

Возможный дубликат [boost interprocess с именем mutex остается приобретенным после сбоя] (http://stackoverflow.com/questions/7808431/boost-interprocess-named-mutex-remains-acquired-after-a-crash) –

+0

@curiousguy - Например, TaskManager может убить процесс нечисто. –

ответ

0

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

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

Если вам действительно нужно это сделать, я бы предположил, что вы, вероятно, не используете подходящий инструмент для работы.

+0

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

+0

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

+0

@KevinHopps: Один из способов - проверить, все ли процесс по-прежнему связан с соответствующим вызовом вашей платформы ('kill (0)' на платформах POSIX). Как я уже сказал, если вы считаете, что вам это нужно, вы, вероятно, используете неправильный инструмент для работы в первую очередь. –

1

Если вы по какой-то причине убьете свое приложение, вы можете разблокировать эту блокировку либо путем выхода из системы Windows, либо путем выполнения команды mutex.unlock();