Основные направления борьбы с тупиками.

Основные направления борьбы с тупиками:

1. Игнорировать данную проблему

2. Обнаружение тупиков

3. Восстановление после тупиков

4. Предотвращение тупиков за счет тщательного выделения ресурсов или нарушения одного из условий возникновения тупиков.

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

Предотвращение тупиков и алгоритм банкира.

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

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

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

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

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

У алгоритма банкира имеются серьезные недостатки, из-за которых разработчик может выбрать другой подход для решения проблемы тупиков:

· Алгоритм банкира исходит из фиксированного количества ресурсов.

· Он требует, чтобы число работающих пользователей оставалось постоянным

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

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

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

Предотвращение тупиков за счет нарушения условий возникновения тупиков.

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

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

Hарушение условия ожидания дополнительных ресурсов

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

· Если же процесс, удерживает определенные ресурсы и получает отказ в выделении ему дополнительных ресурсов, то он должен освободить свои первоначальные ресурсы и, при необходимости, запросить их снова вместе с дополнительными.

Таким образом, один из способов - заставить все процессы затребовать все свои ресурсы перед выполнением (все или ничего). Если система в состоянии выделить процессу все необходимое, он может работать до завершения. Если хотя бы один из ресурсов занят, процесс будет ждать.

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

Нарушение принципа неперераспределяемости.

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

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