Алгоритм страуса.

Простейший подход - игнорировать проблему тупиков.

Различные люди реагируют на подобную стратегию по-разному.

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

Инженеры задают вопрос: как часто возникает данная проблема и как часто система виснет по другим причинам? Если тупик встречается раз в пять лет, но аварийный останов системы из-за отказов оборудования, ошибок компиляторов, багов ОС происходит раз в месяц, большинство инженеров не пожелают пожертвовать производительностью или удобством, чтобы ликвидировать тупик.

Максимальное число открытых файлов аналогичным образом ограничено размером таблицы индексных узлов. С ними может произойти аналогичная ситуация. Пространство выгрузки на диске - другой лимитируемый ресурс. Фактически любая таблица в ОС - конечный ресурс.

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

Обнаружение тупика это установление факта, что возникла тупиковая ситуация и определение процессов и ресурсов, вовлеченных в эту ситуацию. Как правило, алгоритмы обнаружения применяются, когда выполнены первые три необходимых условия возникновения тупиковой ситуации. Затем проверяется наличие режима кругового ожидания. При этом активно используются уже упоминавшиеся графы распределения ресурсов.

Рассмотрим модельную ситуацию :

· Процесс A удерживает ресурс R и ожидает ресурс S.

· Процесс B претендует на ресурс T.

· Процесс C претендует на ресурс S.

· Процесс D удерживает ресурс U и ожидает ресурсы S и T.

• Процесс E удерживает ресурс T и ожидает ресурс V.
• Процесс F удерживает ресурс W и ожидает ресурс S.
• Процесс G удерживает ресурс V и ожидает ресурс U.

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

Рис. 7.2 (а) Граф ресурсов. (б) Цикл, извлеченный из графа (a).

Из рисунка видно, что имеется цикл, моделирующий условие кругового ожидания, и процессы D,E,G в тупиковой ситуации.

Визуально легко обнаружить наличие тупика, но нужны также формальные алгоритмы, реализуемые на компьютере.

Один из таких алгоритмов описан в [12], там же можно найти ссылки на другие алгоритмы.

Существуют и другие способы обнаружения тупиков, применимые также в ситуациях, когда имеется несколько ресурсов каждого типа. Так в [22] описан способ, называемый редукцией графа распределения ресурсов, а в [12] матричный алгоритм.

Если же тупиковая ситуация возникла, то не обязательно снимать с выполнения все заблокированные процессы. Существуют формальные, программно-реализованные методы распознавания тупиков, основанные на ведении таблиц распределения ресурсов и таблиц запросов к занятым ресурсам. Анализ этих таблиц позволяет обнаружить взаимные блокировки.

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

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

Сложность восстановления обусловлена рядом факторов.

· в большинстве систем нет достаточно эффективных средств приостановить процесс, вывести его из системы и возобновить впоследствии

· если даже такие средства есть, то их использование требует затрат и внимания оператора

· восстановление после серьезного тупика может потребовать много работы

Можно:

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

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

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

2) можно совершить "откат"

некоторых процессов до так называемой контрольной точки, в которой запоминается вся информация, необходимая для восстановления выполнения программы с данного места(восстановление через откат назад). Контрольные точки расставляются в программе в местах, после которых возможно возникновение тупика.

3) Восстановление через ликвидацию одного из процессов

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

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

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

Проблема предотвращения тупиков может быть решена несколькими способами.

Первый способ - разрешить программе в каждый момент времени держать закрытым только один семафор. Метод прост и решает проблему в корне, но часто оказывается неприемлемым.

Более приемлемым оказывается соглашение, что семафоры всегда должны закрываться в определенном порядке. Этот порядок может быть любым, важно только чтобы он всегда соблюдался.

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

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

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

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

Алгоритм банкира. Идея: можно избежать тупиковой ситуации, если рациональным образом использовать ресурсы, придерживаясь определенных правил.

Алгоритм банкира предложен Дейкстрой. Он, как бы имитирует действия банкира, который, располагая определенным источником капитала, принимает ссуды и выдает платежи.

Предположим, что у системы в наличии n устройств, например лент. Суть алгоритма состоит в следующем.

ОС принимает запрос от пользовательского процесса, если его максимальная потребность не превышает n.

Пользователь гарантирует, что если ОС в состоянии удовлетворить его запрос, то все устройства будут возвращены системе в течение конечного времени.

Текущее состояние системы называется надежным, если ОС может обеспечить всем процессам их выполнение в течение конечного времени.

В соответствии с алгоритмом банкира выделение устройств возможно, только если состояние системы остается надежным.

Рассмотрим пример надежного состояния для системы с тремя пользователями и 12-ю устройствами, где 10 устройств задействовано, а 2 имеется в наличии. Пусть текущая ситуация такова:

Данное состояние надежно. Последующие действия системы могут быть таковы. Вначале удовлетворить запросы второго пользователя, затем дождаться, когда он выполнит свою работу и освободит свои 6 устройств. Затем можно обслужить остальных пользователей. То есть, система удовлетворяет только те запросы, которые оставляют ее в надежном состоянии и отклоняет остальные.

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