
Обнаружение тупиков. Графы распределения ресурсов
Обнаружение тупика - это установление факта, что возникла тупиковая ситуация, и определение процессов и ресурсов, вовлеченных в эту тупиковую ситуацию. Алгоритмы обнаружения тупиков, как правило, применяются в системах, где выполняются первые три необходимых условия возникновения тупиков, и определяют, не создался ли режим кругового ожидания.
Для обнаружения тупиков распределение ресурсов и запросы процессов изображаются в виде направленного графа. Квадраты обозначают процессы, большие круги - классы идентичных ресурсов, а малые - количество идентичных ресурсов каждого класса.
P1
R1
ПроцессP1
запрашивает один из ресурсов R1
R2
P2
Ресурс R2 выделен процессу Р2
P3 R3 P4
ПроцессР3
запрашивает ресурс R3,
который выделен процессу
P4
Рис.6 Граф запросов и распределения ресурсов
Ранее мы привели на рис.5 вариант “кругового ожидания”, типичного для системы в состоянии тупика.
Графы запросов и распределения ресурсов динамично меняются по мере того, как процессы запрашивают ресурсы и получают их в свое распоряжение, а по истечении некоторого времени возвращают системе.
Одним из способов обнаружения тупиков, является приведение, или редукция графа - это позволяет определить процессы, которые могут завершиться, и процессы, которые будут оставаться в тупиковой ситуации.
Редукция графа на конкретный процесс изображается исключением стрелок, идущих к процессу от ресурсов и стрелок к ресурсам этого процесса, такая редукция эквивалентна такой ситуации, когда данный процесс завершился и возвратил ресурсы системе. Если граф можно редуцировать на все процессы, значит тупиковой ситуации нет, а если этого сделать нельзя, то все “нередуцируемые” процессы образуют набор процессов, вовлеченных в тупиковую ситуацию. Заметим, что порядок, в котором осуществляется редукция графа, не имеет значение.
P2
R1 R1 P2
А) Б)
P3 P3
P1 R2 P1 R2
Редуцирование на процесс Р3
P2
R1 R1 P2
В) Г)
P3 P3
P1 R2 P1 R2
Редуцирование на процесс Р1 Редуцирование на процесс Р2
Рис.7 Редукция графа
На рис.7 показана ситуация, в которой для конкретного набора процессов тупиковой ситуации нет. Если же мы попытаемся редуцировать граф, приведенный на рис.5, то легко обнаружим, что система находится в тупиковой ситуации.
Восстановление после тупиков
Систему, находящуюся в тупике, необходимо вывести из него, для чего требуется нарушить одно или несколько необходимых условий его существования. Очевидно, что в этом случае один или несколько процессов потеряют, частично или полностью, проделанную ими работу.
Восстановление после тупика может выполняться путем принудительного вывода одного или нескольких процессов из системы, чтобы можно было использовать их ресурсы.
Целесообразным способом восстановления после тупиков является эффективный механизм приостановки/возобновления процессов, что позволяет процессы кратковременно переводить в состояние ожидания, а затем активизировать ожидающие процессы без потери результатов работы. Заметим, что средства рестарта системы с контрольной точки, реализованные во многих системах, обеспечивают приостановку/возобновление с потерей результата после последней контрольной точки.
Отметим, что тупики могут приводить к катастрофическим последствиям в системах реального времени, поэтому в таких системах риски возникновения тупиковых ситуаций должны быть максимально устранены.
10Coffman E.G., Elphick M., Shoshani A. System Deadlock. Computing Surveys, Vol 3, No 2, 1971, pp.67-78.
11Havender J.W. Avoiding Deadlick in Multitasking System. IBM Systems Journal. Vol 7, No 2, 1968, hh.74-84
12Dijkstra E.W. Cooperating Sequential Processes. Technological University, Eindhoven, Nitherlands,1965.