2.5.2.3.5 Выход из взаимоблокировки
- Восстановление при помощи принудительной выгрузки ресурса. Как правило, требует ручного вмешательства (например: принтер).
- Восстановление через откат. Состояние процессов записывается в контрольных точках, и в случае тупика можно сделать откат процесса на более раннее состояние, после чего он продолжит работу снова с этой точки.
- Восстановление путем уничтожения процесса. Самый простой способ. Ге обязательно снимать с выполнения все заблокированные процессы. Можно снять только часть из них, при этом освобождаются ресурсы, ожидаемые остальными процессами.
2.5.2.4 Динамическое избежание взаимоблокировок
2.5.2.4.1 Траектории ресурсов
Рассмотрим модель из двух процессов и двух ресурсов.
А1 - запрос принтера процессом А, А2 - запрос плоттера процессом А,
А3 - освобождение принтера процессом А, А4 - освобождение плоттера процессом А
В1 - запрос плоттера процессом В, В2 - запрос принтера процессом В,
В3 - освобождение плоттера процессом В, В4 - освобождение принтера процессом В.
Рис. 2.19 Динамическое избежание взаимоблокировок
Т.к. процессор предоставляется поочередно, траектория может продолжаться только параллельно осям. Чтобы избежать тупика, процессам надо обойти прямоугольник, охватывающий всю заштрихованную область.
2.5.2.4.2 Безопасные и небезопасные состояния
В безопасном состоянии система может гарантировать, что все процессы закончат свою работу.
Рассмотрим систему, в которой существует 10 экземпляров ресурса и 3 процесса.
Процесс А занял 3 экземпляра, но ему необходимо 9. В этой ситуации можно спланировать так, что вначале запускается процесс В, потом С и потом А. Процессы заканчивают работу без тупиковой ситуации.
Рассмотрим другую ситуацию.
Процесс А занял 4 экземпляра ресурса.
Возникает небезопасное состояние, поскольку возможен тупик. В принципе, процесс А может в какой то момент ресурс освободить и тупика не возникнет. Видно, что в этом случае не стоило давать ресурс процессу А.
2.5.2.4.3 Алгоритм банкира для одного вида ресурсов
Рассмотрим систему. Банкир может дать 10 кредитов (ресурсы). К нему попеременно обращаются 4 клиента.
Алгоритм банкира:
Банкиру поступает запрос от клиента на получение кредита.
Банкир проверяет, приводит ли этот запрос к небезопасному состоянию.
Банкир в зависимости от этого дает или отказывает в кредите.
Рис. 2.20 Алгоритм банкира
2.5.2.4.4 Алгоритм банкира для несколько видов ресурсов
Рассмотрим систему:
E=(6342) - существующие ресурсы, P=(5322) - занятые ресурсы, A=(1020) - доступные ресурсы
Алгоритм поиска безопасного или небезопасного состояния:
Рис. 2.21 Алгоритм банкира для несколько видов ресурсов
Если состояние безопасное, то ресурс выделить можно, если нет - нельзя.
На практике все эти алгоритмы сложно реализовать.
2.5.2.5 Предотвращение условий, необходимых для взаимоблокировок
1. Предотвращение условия взаимного исключения.
Можно минимизировать количество процессов, борющихся за ресурсы. Например, с помощью спулинга для принтера, когда только демон принтера работает с принтером.
2. Предотвращение условия удержания и ожидания.
Один из способов достижения этой цели заключается в том, что процесс должен запрашивать все необходимые ресурсы до начала работы. Если хоть один ресурс недоступен, то процессу вообще ничего не предоставляется.
3. Предотвращение условия отсутствия принудительной выгрузки ресурса.
Разрешить ОС отбирать ресурсы, но могут быть проблемы.
4. Предотвращение условия циклического ожидания.
Способы предотвращения:
Процесс сначала должен освободить занятый ресурс, прежде чем занять новый.
Можно пронумеровать все ресурсы, и процессы должны получать ресурсы только по возрастающему (убывающему) порядку.
2.5.2.6 Системные средства синхронизации процессов
В случае синхронизации потоков разных процессов операционная система должна предоставлять потокам системные объекты синхронизации, которые были бы видны для всех потоков, даже если они принадлежат разным процессам и работают в разных адресных пространствах. Примерами таких синхронизирующих объектов ОС являются системные семафоры, мьютексы, события, таймеры и другие.
Чтобы процессы могли разделять синхронизирующие объекты, в разных ОС используются разные методы: возврат указателя на объект, доступного всем родственным процессам, наследующим характеристики общего родительского процесса; указание в запросах на создание объектов синхронизации имен, которые должны быть им присвоены. Далее эти имена используются разными процессами для манипуляций объектами синхронизации. В таком, случае работа с синхронизирующими объектами подобна работе с файлами (создавать, открывать, закрывать, уничтожать).
Все синхронизирующие объекты могут находиться в двух состояниях:
- сигнальном
- несигнальном (свободном).
Для каждого объекта смысл, вкладываемый в понятие «сигнальное состояние», зависит от типа объекта. Так, например, поток переходит в сигнальное состояние тогда, когда он завершается. Процесс переходит в сигнальное состояние тогда, когда завершаются все его потоки. Файл переходит в сигнальное состояние в том случае, когда завершается операция ввода-вывода для этого файла. Для остальных объектов сигнальное состояние устанавливается в результате выполнения специальных системных вызовов. Приостановка и активизация потоков осуществляются в зависимости от состояния синхронизирующих объектов ОС.
Потоки с помощью специального системного вызова сообщают операционной системе о том, что они хотят синхронизировать свое выполнение с состоянием некоторого объекта, при этом поток может ожидать установки сигнального состояния не одного объекта, а нескольких. Поток может попросить ОС активизировать его при установке либо одного из указанных объектов, либо всех объектов. В качестве аргумента системного вызова Wait() поток может указать максимальное время, которое он будет ожидать перехода объекта в сигнальное состояние, после чего ОС должна его активизировать в любом случае. Может случиться, что установки некоторого объекта в сигнальное состояние ожидают сразу несколько потоков. В зависимости от объекта синхронизации в состояние готовности могут переводиться либо все ожидающие это событие потоки, либо один из них.
Синхронизация тесно связана с планированием потоков. Любое обращение потока с системным вызовом Wait(X) влечет за собой действия в подсистеме планирования:
- поток снимается с выполнения и помещается в очередь ожидающих потоков
- из очереди готовых потоков выбирается и активизируется новый поток.
- при переходе объекта в сигнальное состояние ожидающий этот объект поток (или потоки) переводится в очередь готовых к выполнению потоков. В обоих случаях осуществляется перепланирование потоков, при этом если в ОС предусмотрены изменяемые приоритеты и/или кванты времени, то они пересчитываются по правилам, принятым в этой операционной системе.