2курсИБ(ОС) / lab5теория

«распечатать файл» или «отправить письмо», а какие ресурсы нужны системе для выполнения подобных запросов — решать должен не он.

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

Обнаружение взаимоблокировок.

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

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

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

На рисунке — процесс P1 запрашивает один из двух идентичных ресурсов типа R1. Запрос обрывается на границе большого круга — т. е. находится на стадии рассмотрения.

Процессу P2 выделен один из идентичных ресурсов типа R2 (стрелка идет от малого кружка).

Процесс P3 запрашивает ресурс R3, уже выделенный процессу P4.

Небольшая система в тупиковой ситуации: это как раз пример «кругового ожидания».

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

которые будут оставаться в тупиковой ситуации.

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

Проведем редуцирование сначала на процесс P9 (будет удалена единственная стрелка из ресурса R7). Затем проведем редуцирование на процесс P7 (исчезнут стрелки из ресурса R7 и в ресурс R6). Наконец, редуцируем на процесс P8 (удаляются две оставшиеся стрелки).

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

Восстановление после взаимоблокировок.

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

Во-вторых, в большинстве ОС нет достаточно эффективных средств, позволяющих приостановить процесс на неопределенно долгое время, вывести его из системы и возобновить его выполнение позже (не потеряв при этом проделанную им работу). Например, процессы реального времени должны работать непрерывно и не допускают приостановки и последующего возобновления. Даже если такие средства (приостановки / возобновления) существовали бы, вряд ли их можно было бы применять без участия человека (более того, квалифицированного системного администратора). Еще момент — восстановление после взаимоблокировки осложняется еще и большим количеством вовлеченных в нее процессов.

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

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

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

Механизм приостановки / возобновления (suspend / resume) процессов позволяет кратковременно выводить процессы в состояние ожидания (высвобождая занятые ими ресурсы), а затем активизировать ожидающие процессы (причем без потери результатов работы). Исследования в этой области имеют большое значение не только для выхода из тупиковых ситуаций. Этот механизм весьма эффективен, если необходимо на какое-то время выключить систему, а затем запустить ее вновь с той же точки без потери промежуточных результатов. Вероятно, «спящий режим» в Windows используется многими (содержимое памяти, регистров и т. п. записываются на энергонезависимые носители — например, жесткий диск; после чего питание может быть выключено).

Всовременных БД широко применяется механизм контрольных точек / точек отката (checkpoint / rollback) — предшественник механизма приостановки / возобновления. В этом случае результаты теряются, но лишь те, которые были получены после последней контрольной точки. Внесение каких-либо изменений в БД организуется с помощью транзакций: изменения, выполненные в рамках одной транзакции, фиксируются в БД только в том случае, если выполнение транзакции завершилось успешно.

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