Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
LEKTsII_PO_OPERATsIONN_M_SISTEMAM_I_SREDAM.doc
Скачиваний:
49
Добавлен:
26.11.2019
Размер:
2.27 Mб
Скачать

1. Граф распределения ресурсов

Задачу установления факта возникновения тупиковой ситуации удобно ре­шать с помощью графа распределения ресурсов. На рис. 1 представлены два основных типа отношений (рис. 1, а) на графе (запрос ресурса и владение им) и простейший пример системы в состоянии кругового ожидания —(тупика) (рис 1, б)

Р ис. 1. Примеры графа распределения ресурсов

Для обнаружения тупиков выполняется редукция (приведение) графа. Су­ществует правило редукции — для каждого незаблокированного процесса (т. е. процесса, все запросы которого могут быть удовлетворены) нужно уб­рать все входящие и исходящие дуги. Граф полностью приводим, если после редукции он не содержит ни одной дуги. В системе отсутствуют тупиковые ситуации, если соответствующий граф полностью приводим.

2. Сеть Петри — помеченный ориентированный граф с двумя типами вершин: позициями и переходами. Позиции изображаются кругами, переходы — квадратами, а пометки — жирными точками в позициях.

Разметка — функция, которая ставит в соответствие пометкам позиции це­лое неотрицательное число. Разметка может быть изменена с помощью сра­батывания (запуска) перехода. Переход называется запускаемым, если в каж­дой позиции, из которой ведет стрелка в данный переход, есть хотя бы одна метка. Запуск перехода заключается в том, что из каждой позиции, из кото­рой ведет стрелка, число пометок уменьшается на единицу. А в каждую по­зицию, в которую ведет стрелка, число пометок увеличивается на единицу.

Семантически позиции удобно рассматривать как некоторые условия, а пе­реходы как некоторые события, происходящие в системе. Разметка называ­ется живучей, если каждый из переходов в системе может быть запущен бес­конечное число раз. Когда достигается разметка, при которой ни один из переходов не может быть запущен, говорят, что сеть Петри "зависла". Если разметка живучая, то система не остановится.

Р ис. 2. Моделирование взаимного исключения с помощью сети Петри

На рис. 2 выполнено моделирование взаимного исключения между двумя процессами с помощью сети Петри.

Позиции, помеченные КУ1 и КУ2, представляют соответственно критические участки первого и второго процесса. При текущей разметке могут быть за­пущены переходы Р11 или Р21. Если запускается переход Р11, то позиция КУ1 получает пометку (система входит в критический участок). При этом второй процесс не может войти в КУ2, поскольку разделяемая позиция явля­ется пустой. Теперь может быть запущен только переход Р12. После его за­пуска система возвращается в исходное состояние.

3. Вычислительные схемы

Сеть Петри не обеспечивает полной общности с вычислительной точки зре­ния. Например, сетью Петри нельзя смоделировать оператор отрицания ("не"). Существует еще одна структура под названием "вычислительная схе­ма", которая эту проблему решает.

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

Рассмотрим еще один пример тупика. Пусть двум процессам, выполняющимся в режиме мультипрограммирования, для выполнения их работы нужно два ресурса, например, принтер и диск. На рисунке 3(а) показаны фрагменты соответствующих программ. И пусть после того, как процесс А занял принтер (установил блокирующую переменную), он был прерван. Управление получил процесс В, который сначала занял диск, но при выполнении следующей команды был заблокирован, так как принтер оказался уже занятым процессом А. Управление снова получил процесс А, который в соответствии со своей программой сделал попытку занять диск и был заблокирован: диск уже распределен процессу В. В таком положении процессы А и В могут находиться сколь угодно долго. В зависимости от соотношения скоростей процессов, они могут либо совершенно независимо использовать разделяемые ресурсы (г), либо образовывать очереди к разделяемым ресурсам (в), либо взаимно блокировать друг друга (б). Тупиковые ситуации надо отличать от простых очередей, хотя и те и другие возникают при совместном использовании ресурсов и внешне выглядят похоже: процесс приостанавливается и ждет освобождения ресурса. Однако очередь - это нормальное явление, неотъемлемый признак высокого коэффициента использования ресурсов при случайном поступлении запросов. Она возникает тогда, когда ресурс недоступен в данный момент, но через некоторое время он освобождается, и процесс продолжает свое выполнение. Тупик же, что видно из его названия, является в некотором роде неразрешимой ситуацией.

Рис. 3. (a) фрагменты программ А и В, разделяющих принтер и диск; (б) взаимная блокировка (клинч); (в) очередь к разделяемому диску; (г) независимое использование ресурсов

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

Необходимые условия возникновения тупиковых ситуаций.

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

  2. Процессы удерживают за собой ресурсы, выделенные им, в то же время ожидают выделения дополнительных ресурсов (условие ожидания ресурсов).

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

Проблема тупиков включает в себя следующие задачи:

  • предотвращение тупиков,

  • распознавание тупиков,

  • восстановление системы после тупиков.

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

Для того чтобы обеспечить написание корректных программ, было предложено высокоуровневое средство синхронизации - «монитор» - это набор процедур, переменных и структур данных. Процессы могут вызывать процедуры монитора, но не имеют доступа к внутренним данным монитора. Мониторы имеют свойства, позволяющие достичь взаимоисключения процессов, а именно: только один процесс может быть активным по отношению к монитору, это достигается не за счет программирования, а на уровне компилятора. Компилятор обрабатывает вызовы процедур монитора таким образом, что первые несколько инструкций этой процедуры проверяют – не активен ли какой-либо процесс по отношению к монитору. Если «ДА», то вызывающий процесс приостанавливается, пока другой не освободит монитор. Но когда процессы имеют собственную ОП, используется механизм семафорных операций. В таких системах синхронизация реализована с помощью обмена сообщениями.

Методы борьбы с тупиками

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

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

  • предотвращение тупика;

  • обход тупика;

  • распознавание тупика с последующим восстановлением.

Предотвращение тупиков

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

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

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

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

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

Условие кругового ожидания можно исключить, предотвращая образование цепи запросов. Это можно обеспечить с помощью принципа иерархического выделения ресурсов. Все ресурсы образуют некоторую иерархию. Процесс, затребовавший ресурс на одном уровне, может затем потребовать ресурсы только на более высоком уровне. Он может освободить ресурсы на данном уровне только после освобождения всех ресурсов на всех более высоких уровнях. После того как процесс получил, а потом освободил ресурсы данного уровня, он может запросить ресурсы на том же самом уровне. Пусть имеются процессы ПР1 и ПР2, которые могут иметь доступ к ресурсам R1 и R2, причем R2 находится на более высоком уровне иерархии. Если ПР1 захватил R1, то ПР2 не может захватить R2, так как доступ к нему проходит через доступ к R1, который уже захвачен ПР1. Таким образом, создание замкнутой цепи исключается. Иерархическое выделение ресурсов часто не дает никакого выигрыша, если порядок использования ресурсов, определенный в описании процессов, отличается от порядка уровней иерархии. В этом случае ресурсы будут использоваться крайне неэффективно.

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

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

Распознавание тупика требует дальнейшего восстановления.

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

  • принудительный перезапуск системы, характеризующийся потерей информации обо всех процессах, существовавших до перезапуска;

  • принудительное завершение процессов, находящихся в тупике;

  • принудительное последовательное завершение процессов, находящихся в тупике с последующим вызовом алгоритма распознавания после каждого завершения до исчезновения тупика;

  • перезапуск процессов, находящихся в тупике, с некоторой контрольной точки, то есть из состояния, предшествовавшего запросу на ресурс;

  • перераспределение ресурсов с последующим последовательным перезапуском процессов, находящихся в тупике.

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

Контрольные вопросы:

Проблемная ситуация

Представим себе двух студентов, которым нужно поработать с одной и той же книгой, имеющейся в библиотеке в единственном экземпляре. Они одновременно пришли в библиотеку, но один из них сначала пошел в читальный зал и, заняв единственное свободное место, отправился в книжное хранилище, а другой — наоборот, начал с того, что получил книгу, а потом пошел в читальный зал искать место. В результате ни один из них не может выполнить работу, так как для этого им не хватает необходимого ресурса. Можно ли считать, что в данном случае произошла взаимная блокировка, или, другими словами, клинч?

Ответ: Нет, в данном случае мы имеем дело не с клинчем, а с очередью. Действительно, студент, ожидающий в читальном зале, может быть «разблокирован» в результате освобождения какого-либо другого места в читальном зале, а затем он, выполнив свою работу и сдав книгу, «разблокирует» другого студента, ожидающего в книжном хранилище. Для того чтобы ситуация могла быть названа клинчем, следует дополнить задачу еще одним условием—в читальном зале имеется только одно рабочее место.

. Вопросы для самоконтроля:

  1. Какие вычислительные процессы называются параллельными и почему? Какие параллельные процессы называются независимыми, а какие – взаимодейтсвующими?

  2. Объясните команду “проверка и установка”.

  3. Что такое самфоры Дейкстры? Чем обеспечивается взаимное исключение при выполнении P- и V-примитивов?

  4. Что такое mutex?

  5. Изложите алгоритм решения задачи “поставщик-потребитель”.

  6. Изложите алгоритм решения задачи “читатели-писатели”.

  7. Что такое монитора Хоара?

Вопросы для самоконтроля:

  1. Что такое тупиковое состояние? Перечислите условия, при которых возникает тупик.

  2. Какие стратегии работы с тупиками вы знаете?

  3. Какие графические средства используются для работы с тупиками?

  4. Что собой представляет «предотвращение тупика»? Как его можно реализовать?

  5. Что представляет собой «обход тупика»? Приведите алгоритм банкира Дейкстры.

  6. Что такое «опасное состояние»? Приведите пример опасного состояния.

  7. Изложите алгоритм обнаружения тупика по наличию замкнутой цепочки запросов.

Домашнее задание:

Конспект лекций

Лекция 2 (2/4)

Проверка Д/З:

1). У 3 чел. Проверить конспекты + ОС будущего

2). 3 чел. спросить по предыдущему (см. выше)