Обзор экзамена по операционной системе. Глава 3. Предотвращение взаимоблокировок.

Предотвращение тупиковой ситуации: просто устраните одно из четырех условий тупиковой ситуации.

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

1. Нарушениеусловия «запросить и удержать»

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

Решение:

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

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

2. Уничтожитьусловие «непреимущественного права»

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

Недостатки этого решения:

1. Это сложнее реализовать.
2. Освобождение приобретенных ресурсов может привести к сбою предыдущего этапа работы. Поэтому этот метод обычно подходит только для ресурсов, состояние которых легко сохранить и восстановить, например ЦП.
3. Многократные запросы и высвобождение ресурсов увеличивают нагрузку на систему и снижают ее пропускную способность.
4. Пока определенный ресурс временно недоступен, от всех ранее полученных ресурсов необходимо отказаться и повторно применить в будущем. Если это будет происходить постоянно, это приведет к голоданию процесса.

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

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

Недостатки этой стратегии:

  1. Добавлять новое оборудование неудобно, так как может потребоваться переназначение всех номеров;
  2. Порядок, в котором процесс фактически использует ресурсы, может не соответствовать порядку возрастания чисел, что приведет к бесполезной трате ресурсов;
  3. Ресурсы должны применяться в определенном порядке, что усложняет пользовательское программирование.

Избегайте тупика:

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

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

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

Если система находится в безопасном состоянии, тупиковой ситуации точно не произойдет . Таким образом ,
перед выделением ресурсов вы можете заранее оценить, приведет ли это выделение к переходу системы в небезопасное состояние, чтобы решить, следует ли удовлетворять запрос на выделение ресурсов. Это также основная идея «Алгоритма Банкира» .
Подробную информацию об использовании алгоритма банкира для предотвращения тупиков см. в разделе: Операционная система — алгоритм банкира для предотвращения тупиков_Использование алгоритма банкира для предотвращения тупиков_Блог для написания стихов с помощью программирования — блог CSDN

Пример алгоритма банкира:

Предположим, что в системе имеется 5 процессов {P0, P1, P2, P3, P4} и три типа ресурсов {A, B, C}. Число различных ресурсов равно 10, 5 и 7 соответственно. Распределение ресурсов в момент времени T0, как показано на рисунке:

Макс Аллокайтон Нуждаться Доступный
А Б С А Б С А Б С А Б С
Р0 7 5 3 0 1 0 7 4 3 3 3 2(2,3,0)
П1 3 2 2 2 0 0(3,0,2) 1 2 2(0,2,0)
П2 9 0 2 3 0 2 6 0 0
П3 2 2 2 2 1 1 0 1 1
П4 4 3 3 0 0 2 4 3 1

Безопасность во время T0: Используя алгоритм безопасности для анализа распределения ресурсов во время T0, можно увидеть, что существует последовательность безопасности {P1, P3, P4, P2, P0} в момент T0, поэтому система безопасна.

Работа Нуждаться Распределение Работа+Распределение Заканчивать
А Б С А Б С А Б С А Б С
П1 3 3 2 1 2 2 2 0 0 5 3 2 истинный
П3 5 3 2 0 1 1 2 1 1 7 4 3 истинный
П4 7 4 3 4 3 1 0 0 2 7 4 5 истинный
П2 7 4 5 6 0 0 3 0 2 10 4 7 истинный
Р0 10 4 7 7 4 3 0 1 0 10 5 7 истинный

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

Первый случай: P1 запрашивает ресурсы: P1 отправляет вектор запроса Request(1,0,2), и система проверяет по алгоритму банкира.

Запрос(1,0,2)<=Потребность(1,2,2) Запрос(1,0,2)<=Доступно(3,3,2)

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

Используя алгоритм безопасности для проверки, также можно получить защитную последовательность {P1, P3, P4, P0, P2}, поэтому ей присваивается

Работа Нуждаться Распределение Работа+Распределение Заканчивать
А Б С А Б С А Б С А Б С
П1 2 3 0 0 2 0 3 0 2 5 3 2 истинный
П3 5 3 2 0 1 1 2 1 1 7 4 3 истинный
П4 7 4 3 4 3 1 0 0 2 7 4 5 истинный
Р0 7 4 5 7 4 3 0 1 0 7 5 5 истинный
П2 7 5 5 6 0 0 3 0 2 10 5 7 истинный

Второй случай: P4 запрашивает ресурсы: P4 выдает вектор запроса Request(3,3,0), и система проверяет по алгоритму банкира

Запрос(3,3,0)<=Потребность(4,3,1)

Request(3,3,0)>Available(2,3,0) позволяет P4 ждать

Третья ситуация: P0 запрашивает ресурсы: P0 отправляет вектор запроса Request(0,2,0), и система проверяет по алгоритму банкира:

Запрос(0,2,0)<=Потребность(7,4,3)

Запрос(0,2,0)<=Доступно(2,3,0)

Система сначала предполагает, что ресурсы выделены для P0, а затем вносит изменения.

Макс Аллокайтон Нуждаться Доступный
А Б С А Б С А Б С А Б С
Р0 7 5 3 0 3 0 7 2 3 2 1 0
П1 3 2 2 3 0 2 0 2 0
П2 9 0 2 3 0 2 6 0 0
П3 2 2 2 2 1 1 0 1 1
П4 4 3 3 0 0 2 4 3 1

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

Guess you like

Origin blog.csdn.net/m0_53345417/article/details/130508038