29Обнаружение тупиков

За счет различных дорогостоящих вычислений можно установить, существуют ли процессы, находящиеся в состоянии тупика. Чтобы выполнить эти вычисления, ОС должна вести список тех ресурсов, которые ждет каждый заблокированный процесс, и список тех процессов, которые держат каждый недоступный ресурс. Алгоритм распознавания замкнутых цепей (Deadlock detection) можно выполнять с любой нужной частотой. Например, часто – всякий раз, когда запрос на ресурс отклоняется, или редко – раз в час или, когда загруженность СРU падает ниже некоторой критической величины (например ниже 40%).

Пусть:

• Available – вектор длины т, определяющий количество допустимых экземпляров для каждого типа ресурсов.

• Allocation – матрица размерностью п  т, определяющая текущее закрепление ресурсов.

• Reguest – матрица размерности п  т, определяющая текущие запросы для всех процессов.

Если Reguest_i j = k, это означает, что процесс Р_i запрашивает k экземпляров ресурса R_j. Как и прежде, будем считать, что векторы Allocation_i, Reguest эквивалентны строкам соответствующих матриц.

Алгоритм обнаружения тупиков может быть построен следующим образом.

Шаг 1. Пусть Work и Finish – векторы размерностью п и т соответственно. Инициализируем:

Work : = Available

Для i = 1, 2, … , n если Allocation_i  0, то есть имеется какое-то отличное от нуля распределения ресурсов, тогда Finishi:=false , иначе Finishi:=true.

Шаг 2. Находим i такое, что одновременно Finish i: = false процесс не завершён и Reguest_i  Work запрос меньше, чем имеется в наличии

В том случае, если искомое i не существует, перейдем к шагу 4 .

Шаг 3.

Finish i : = true

Work : = Work + Allocation_i

Перейдем к шагу 1.

Шаг 4.

Если Finish i : = false для некоторых i 1 , n , тогда система находится в тупике, и в тупиковую ситуацию вовлечены все процессы Р_i, для которых имеет место Finish i : = false.

30Восстановление после тупика

Как только тупик выявлен, должно быть выполнено восстановление (Recovery from leadlock). Это обязательно вызовет перезапуск одного или более процессов. Процессы, находящиеся в тупике, были заблокированы в некоторой точке. Их нужно вернуть в те условия, в которых они могут возобновить свое исполнение. Для большинства процессов перезапуск возможен только с самого начала, и даже в этом случае могут возникнуть некоторые трудности. Процесс может сделать снимок своего исполнения, то есть запомнить информацию о своем состоянии в некоторой контрольной точке. В этом случае при повторном запуске этого процесса не требуется повторять все вычисления, предшествовавшие перераспределению. Контрольные точки обычно вводятся не для того, чтобы помочь восстановлению после тупика, а для того, чтобы продолжить исполнение после возникновения ошибки, особенно при выполнении длинных работ в системах реального времени.

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

• администратор/оператор информирует о тупиковой ситуации и вручную восстанавливает систему;

• система восстанавливает автоматически

При автоматическом восстановлении возможно два подхода:

• принудительно удаляются процессы находящиеся в тупике;

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

При принудительном удалении процессов используется один из двух сценариев:

а) удаляются все процессы, находящиеся в тупике,

б) процессы удаляются по одному. Перед удалением очередного процесса запускается алгоритм обнаружения тупиков.

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

При принудительном освобождении ресурсов необходимо решать три задачи:

а) Выбор процесса (Selection a victim). Иными словами, у какого процесса какие ресурсы должны быть отобраны.

б) Способ возврата процесса в исходное состояние (Rollback). Если ресурс принудительно отобран у процесса, что необходимо делать с этим процессом?

Наилучшее решение – вернуть процесс в такое состояние, когда возможно построение безопасной последовательности процессов. Однако часто процесс, у которого отобран ресурс, запускается заново

в) Предотвращение «наказания» одного и того процесса (Starvation). Чаще всего для того, чтобы не выбирался один и тот же процесс, в критерий выбора включают количество возвратов к исходному состоянию.