4.5. Борьба с тупиками
Существует три основных стратегии борьбы с тупиками:
предотвращение тупиков;
обход тупиков;
распознавание тупика с последующим восстановлением.
Проблема борьбы с тупиками всегда является актуальной для систем с параллельными процессами. Ни одна из перечисленных стратегий не является универсальным "лекарством" от болезни под название "тупик". Иногда, приходится мириться с наличием тупика, особенно в случаях малой вероятности его возникновения, в ряде случаев приходится идти на любые затраты для их нейтрализации или уничтожения, например в ОС реального времени, где тупик может привести к катастрофическим последствиям.
4.5.1. Предотвращение тупиков
Предотвратить тупик можно посредством нарушения условий его возникновения (раздел 4.2): условия взаимного исключения, условия ожидания, условие отсутствия перераспределения и условия кругового ожидания.
Условие взаимного исключения можно нейтрализовать разрешением неограниченного разделения ресурсов. Это приемлемо для повторно входимых программ и ряда драйверов, но неприемлемо для общих переменных, используемых в критических секциях процессов.
Действие условия ожидания можно ослабить предварительным выделением процессу разделяемых ресурсов и блокированием процессов, не получивших предварительно все необходимые ресурсы. Однако такой подход снижает эффективность операционной системы, и не всегда реализуем, т.к. далеко не все процессы "знают" перед началом выполнения список необходимых им ресурсов.
Вредный эффект от условия отсутствия перераспределения ресурсов можно подавить с помощью механизма отнимания ресурса у блокированного процесса. Это сравнительно легко реализуемо посредством запоминания состояния процесса в целях последующего восстановления процесса выполнения процесса. Для процессора этот способ реализуется достаточно легко, но для устройств ввода-вывода крайне нежелателен.
Условие кругового ожидания можно исключить введением иерархии разделяемых ресурсов и введения дисциплины их выделения и освобождения. Захват процессом ресурсов происходит в направлении повышения иерархического уровня захватываемых ресурсов, а освобождение – в направлении понижения уровня освобождаемых ресурсов. Поэтому захват процессом ресурса некоторого уровня заблокирует захват им ресурсов того же или более низкого уровня, но не запретит захват ресурсов более высокого уровня. Освобождение ресурсов происходит в обратном порядке: сначала освобождаются ресурсы верхних уровней иерархии, а затем – нижних.
В целом стратегия предотвращения тупиков является дорогой и используется нечасто [1].
4.5.2. Обход тупиков
Обход тупиков по существу предусматривает запрет входа в опасное состояние. В [1] со ссылкой на литературные источники указывается, чесли вычисления находятся в неопасном состоянии, то существует, по крайней мере, одна последовательность состояний, обходящая опасное состояние. Для того, чтобы реализовать эту стратегию необходимо вести учёт наличия ресурсов, текущих запросов ресурсов и максимально возможного количества ресурсов, которые может запросить каждый параллельный процесс. Обнаружить возможность возникновения тупика даст анализ различных последовательностей действий.
Пример такого анализа приведён в табл. 4.3. В текущий момент времени процессу Р1 выделено три единицы ресурса R, а процессу Р2 – 2 единицы. В этот же момент процессом Р1 запрошена 1 единица, а процессом Р2 – 2 единицы. Полная потребность процессов Р1 и Р2 – 5 и 4 единицы соответственно.
Если удовлетворить заявку процесса Р1, то ему будет выделено четыре единицы, у процесса Р2 уже есть две единицы. В резерве не останется ни одной единицы. Процесс Р2 блокирован, и нет гарантии, что в следующий момент времени процесс Р1 не затребует ещё одну единицу, а тогда процесс Р1 тоже будет заблокирован. Выделение ресурса процессору Р1 приведёт систему к опасному состоянию. Поэтому удовлетворять заявку процесса Р1 в текущий момент не следует.
Таблица 1. Анализ возможности возникновения тупика в текущий момент времени
-
Процесс
Выделено единиц R
Запрошено единиц R
Предельная потребность единиц R
Можно запросить ещё единиц R
Всего в системе единиц R
Р1
3
1
5
1
6
Р2
2
1
3
0
Удовлетворение заявки процесса Р2 также приведёт систему в состояние без единой единицы ресурса в резерве, процесс Р1 уже заблокирован, но процесс Р2 может продолжаться и завершиться. Тогда он освободит сразу три единицы ресурса, что позволит завершиться и процессу Р1. Таким образом, тупик будет обойдён.
Классическое решение проблемы обхода тупика предложил Дейкстра. Его алгоритм называется алгоритмом банкира. Он похож на алгоритм принятия банком решения о возможности выдачи кредита заёмщику без ущерба для своей безопасности (рис. 4.18).
Рис. 4.18. Р-граф алгоритма банкира
В алгоритме используются следующие переменные и массивы:
Вс_Р – общее количество единиц ресурса, которые может предоставить операционная система;
Св_Р – число свободных единиц ресурса;
Прод – флаг, указывающий на необходимость продолжения анализа;
Пол – массив, хранящий количества единиц ресурса, полученных процессами;
Max – максимальные количества единиц, которые вообще могут быть затребованы процесами;
ОСТ – количества единиц ресурса, которые могут быть ещё затребованы процессами;
Зав – признаки завершения процессов.
В начале алгоритма в переменную Св_Р загружается общее число единиц ресурса, которое может быть предоставлено операционной системой. Далее в цикле между узлами 2 и 4 с учётом уже выделенных процессам единиц ресурса вычисляются:
количество свободных единиц ресурса Св_Р;
количества единиц ресурса, которые ещё могут быть затребованы процессами;
признаки завершения процесса (присваивается значение False для подготовки к анализу возможности завершения процессов в цикле между узлами 8 и 11).
Между узлами 6 и 12 организован цикл до получения переменной Прод значения False. В этом цикле вычисляется количество свободных единиц ресурса, с учётом единиц, возвращённых процессами после их завершения. Собственно вычисления осуществляются в цикле, организованном между узлами 7 и 11. Процесс считается завершённым, а единицы ресурса возвращаются в переменную Св_Р, если количество единиц Ост(i), которые ещё может затребовать процесс, не больше количества свободных единиц ресурса. Если все процессы могут завершиться, то переменная Св_Р примет первоначальное значение и станет равной переменной Вс_Р. В этом случае система не придёт в опасное состояние и заявка процесса может быть удовлетворена.
Однако алгоритм банкира не получил распространения в силу ряда причин, важнейшими из которых являются:
допущение о фиксированном числе единиц ресурса, что не всегда соответствует истине;
нереальность требования постоянства числа параллельных работающих процессов (в реальных условиях число параллельных процессов всё время меняется);
затруднения, возникающие из необходимость заранее указывать количество единиц ресурса, которые может затребовать процесс, что не всегда возможно.