Операционные системы - аспекты параллелизма

3.7.1. Обнаружение взаимоблокировки

Для обнаружения блокировки ресурсного типа можно использовать граф "Процесс- ресурс". Направленный граф "Процесс-ресурс" включает:

• Множество вершин V = P _ R, где P={,,…,} – множество процессов, – множество ресурсов;
• Дуги запросов – направлены от процессов к ресурсам, дуга Pi ® Rj означает, что процесс Pi запросил ресурс Rj;
• Дуги распределения – направлены от ресурсов к процессам, дуга Rj ® Pi означает, что ресурс Rj выделен процессу Pi.

Если граф "процесс-ресурс" не имеет циклов, тупиков нет. Если граф "процесс- ресурс" имеет цикл, возможно, тупик существует

Над графом "Процесс ресурс" можно определить операцию редукции: если все запросы какого-либо процесса могут быть удовлетворены, он может быть редуцирован. При редукции все ресурсы, выделенные процессу, освобождаются.

Для операции редукции доказаны следующие утверждения:

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

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

Рис. 3.11. Пример графа "Процесс-ресурс"

На рис. 3.11 представлен пример полностью редуцируемого графа "Процесс-ресурс".

Последовательность редукции: Пр.3, Пр.2, Пр.1.

3.7.2. Предотвращение взаимоблокировок

В 1971 г. Е. Коффман, М. Элфик и А. Шошани сформулировали необходимые условия возникновения взаимоблокировки.

1. Mutual Exclusion (Взаимное исключение) – по крайней мере один из запрашиваемых ресурсов является неделимым (то есть должен захватываться в эксклюзивное использование).
2. Hold and wait (Удержание ресурсов при ожидании) – существует процесс, владеющий некоторым ресурсом и ожидающий освобождения другого ресурса.
3. No preemption (Неперераспределяемость ресурсов) – ресурсы не могут быть отобраны у процесса без его желания.
4. Circular wait (Циклическое ожидание) – существует такое множество процессов {, ,…, }, в котором ждет освобождения ресурса процессом , ждет P3,…, ждет .

Способы предотвращения тупиков основаны на атаке одного из этих условий.

3.7.2.1. Устранения условия "Mutual exclusion"

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

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

3.7.2.2. Устранения условия "No preemption"

Для устранения условия неперераспределяемости ресурсов требуется обеспечить работу с состояниями ресурсов и контекстами работы процесса с ресурсом, поскольку при перераспределении ресурса придется выполнять следующую последовательность операций:

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

Для каких-то ресурсов это возможно (например, для ЦП при передаче его от потока потоку), для других – нет (например, для принтера). К тому же процесс может использовать несколько ресурсов совместно, рассчитывая на то, что эксклюзивное владение одним из ресурсов автоматически означает эксклюзивное владение другими ресурсами. Например, если один из потоков процесса захватил мьютекс, он считает, что может эксклюзивно пользоваться ресурсом, защищаемым данным мьютексом.

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

3.7.2.3. Устранение условия Hold&Wait

Исключение условия удержания и ожидания – задача прикладных программистов.

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

Существует несколько возможных подходов к устранению условия Hold&Wait:

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

При использовании данного подхода также возможно голодание и имеет место неэффективное использование ресурсов.

3.7.2.4. Устранение условия Circular wait

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

1. Можно позволить процессам владеть только одним ресурсом в каждый момент времени.

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

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

Однако, нумерация не всегда возможна (например, если имеются счетные ресурсы и число ресурсов изменяется), к тому же мы опять имеем неэффективное использование ресурсов

3.7.3. Избегание взаимоблокировок

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

Состояние называется безопасным, если для него имеется такая последовательность процессов {, ,…, }, что для каждого Pi ресурсы, которые затребовал Pi, могут быть предоставлены за счет имеющихся незанятых ресурсов и ресурсов, выделенных всем процессам Pj, где j < i.

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

Алгоритм банкира формулируется следующим образом.

При поступлении запроса на выделение ресурса проверяем, является ли состояние, в которое мы перейдем после выделения, безопасным. Если новое состояние безопасно – выделяем ресурс, если новое состояние небезопасно – ресурс не выделяем, блокируем процесс, выполнивший запрос.

Рассмотрим пример.

Предположим, имеются 12 устройств хранения.

Процесс MAX потребность Владеет Может запросить
	10	5	5
	4	2	2
	9	2	7
3 устройства свободны

Текущее состояние безопасно, поскольку существует безопасная последовательность: <,,>: может завершиться, используя только свободные ресурсы, может завершиться, используя свободные ресурсы и ресурсы, которые сейчас выделены процессу , может завершиться, используя свободные ресурсы и ресурсы, которые сейчас выделены процессам и .

Если запросит еще 1 устройство, удовлетворение запроса будет удовлетворено, поскольку после система останется в безопасном состоянии.

Если запросит еще 1 устройство, удовлетворение запроса будет отложено, поскольку оно переведет систему в небезопасное состояние.

Алгоритм банкира можно проиллюстрировать, используя граф "Процесс-ресурс".

При выполнении запроса:

• представляем, что мы его удовлетворили;
• представляем, что все остальные возможные запросы выполнены;
• проверяем, может ли граф "процесс-ресурс" быть полностью редуцирован; если да – выделяем запрошенный ресурс, если нет – блокируем процесс, выполнивший запрос.

3.7.3.1. Восстановление после взаимоблокировки

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

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

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

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

2. Откат выбранного процесса к некоторой контрольной точке или к началу (partial or total rollback)

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

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

3.8. Заключение

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

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