Добавил:

ivanov666 Опубликованный материал нарушает ваши авторские права? Сообщите нам.

Вуз:

Башкирский Государственный Аграрный Университет

Предмет:

[НЕСОРТИРОВАННОЕ]

Файл:

Системное программное обеспечение. Учебник

.pdf

Скачиваний:

Добавлен:

08.09.2026

Размер:

2 Мб

Скачать

☆

<<< < Предыдущая 1 2 3 4 5 6 7 8 9 10 11 1213 / 1813 14 15 16 17 18 > Следующая >>>

121

Глава 4. Параллелизм в операционных системах

но и тупиковые ситуации, или тупики. При этом известны следующие четыре необходимых условия возникновения тупика [1, 4]:

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

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

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

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

В исследованиях по проблеме тупиков выделяют следую-

щие четыре основные направления [1]:

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

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

• обнаружение тупиков;

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

Исследования ученых показали, что возникновение тупиков невозможно, если нарушено хотя бы одно из четырех условий. В частности, была предложена следующая стратегия (три принципа) [1]:

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

2) если процесс, удерживающий определенные ресурсы, получает отказ в удовлетворении запроса на дополнительные ресурсы, этот процесс должен освободить свои первоначальные ресурсы и при необходимости запросить их снова вместе с дополнительными ресурсами;

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

СИСТЕМНОЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ

122

Каждый принцип имеет цель нарушить одно из приведенных выше условий возникновения тупиковой ситуации (кроме первого).

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

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

Отношения между процессами и ресурсами могут быть представлены на графе запросов и распределения ресурсов (рис. 4.3).

При рассмотрении тупиков целесообразно понятие ресурсов системы обобщить и разделить их на два класса [4]: повторно используемые (или системные) ресурсы (типа RR – reusable resource или SR – system resource) и потребляемые (или рас- ходуемые) ресурсы (типа CR – consumable resource).

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

1) число единиц постоянно;

2) каждая единица распределена одному процессу, и толь-

ко, то есть разделение отсутствует;

3) процесс может освободить единицу ресурса, но только

если он ранее получил эту единицу.

Ресурсы типа CR имеют следующие свойства [4]:

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

123

Глава 4. Параллелизм в операционных системах

2) процесс-потребитель уменьшает число единиц ресурса, сначала запрашивая, а затем приобретая (потребляя) одну или более единиц данного вида ресурса.

R1 R2

P1 P2

а б

P3 P4

P5 P6

Р7

P8 R6

Рис. 4.3. Графы запросов и распределения ресурсов: а – процесс P1 запрашивает ресурс R1: в текущий момент запрос от P1 на-

ходится в стадии рассмотрения; б – процессу P2 выделен ресурс типа R2 (один из двух идентичных); в – процесс P3 запрашивает ресурс R3, уже выделенный процессу P4 (ситуация, близкая к тупиковой); г – тупиковая ситуация: процесс P5 запрашивает ресурс R4, который уже выделен процессу P6; процесс P6, в свою очередь, запрашивает ресурс R5, который выделен процессу P5 (пример кругового ожидания, типичного для системы в состоянии тупика); д – процесс P7 запрашивает ресурс R6, уже

выделенный процессу P8 (ситуация, близкая к тупиковой)

СИСТЕМНОЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ

124

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

В качестве примера может быть рассмотрено одно из состояний системы из двух процессов (P1, P2) с ресурсами типа SR (R1, R2). Оно может быть представлено в виде модели Холта, как это показано на рис. 4.4 [4].

Рис. 4.4. Модель Холта

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

Приведем пример тупика на ресурсах типа CR. Пусть есть три процесса: ПР1, ПР2, ПР3 (рис. 4.5), которые вырабатывают соответственно сообщения М1, М2, М3. Эти сообщения представляют собой ресурсы типа CR. Пусть процесс ПР1 является потребителем сообщения М3, процесс ПР2 получает сообщение М1, а ПР3 – сообщение М2 от процесса ПР2, то есть каждый из процессов является поставщиком и потребителем одновре-

125

ПР1

ПР2

ПР3

ПЯ1

ПЯ2

ПЯ3 М2

М3

М1

Глава 4. Параллелизм в операционных системах

менно, а вместе они образуют кольцевую систему передачи сообщений через почтовые ящики (ПЯ) [4].

М2

Рис. 4.5. Пример тупика на ресурсах типа CR

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

1) послать сообщение;

2) ждать сообщение,

то при этом возможны два варианта:

а) вариант без тупиковой ситуации:

ПР1: послать сообщение (ПР2, М1, ПЯ2); ждать сообщение (ПР3, М3, ПЯ1);

ПР2: послать сообщение (ПР3, М2, ПЯ3); ждать сообщение (ПР1, М1, ПЯ2);

ПР3: послать сообщение (ПР1, М3, ПЯ1); ждать сообщение (ПР2, М2, ПЯ3);

б) вариант с тупиковой ситуацией, когда в каждом из процессов эти две процедуры переставить местами. Например, для процесса ПР1:

ПР1: послать сообщение (ПР3, М3, ПЯ1); ждать сообщение (ПР2, М1, ПЯ2).

Приведем пример тупика на ресурсах типа SR. Пусть есть два процесса ПР1 и ПР2, разделяющие два ресурса типа SR:

СИСТЕМНОЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ

126

R1 и R2. Пример последовательности операторов для двух процессов, которые могут привести к тупиковой ситуации для случая, когда взаимное исключение доступов к этим ресурсам реализуется с помощью семафоров S1 и S2, выглядит следующим образом [4]:

ПР1 ПР2

1: P (S2); 5: P (S1);

2: P (S1); 6: P (S2);

3: V (S1); 7: V (S1);

4: V (S2); 8: V (S2).

При этом вариант реализации семафорных примитивов выглядит следующим образом:

P(S): S: =S-1;

If S<0 then {остановить процесс и поместить его в очередь ожидания к семафору S}

V(S): if S<0 then {поместить один из ожидающих процессов очереди семафора S в очередь готовности}

S: =S+1 где P – от голландского Proberen – проверить; V – от голландского Verhogen – увеличить [4].

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

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

127

Глава 4. Параллелизм в операционных системах

са (то есть текущих запросов данного процесса на выделение ему ресурсов) [1].

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

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

Редуцирование исходного графа производится поэтапно.

1. Редуцирование исходного графа на процесс P3 (рис. 4.7).

Рис. 4.7. Редуцирование исходного графа на процесс P3

СИСТЕМНОЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ

2. Редуцирование на процесс P1 (рис. 4.8).

Рис. 4.8. Редуцирование на процесс P1

3. Редуцирование на процесс Р2 (рис. 4.9).

128

Рис. 4.9. Редуцирование на процесс Р2

Таким образом, исходный граф может быть редуцирован на все процессы, и тупиковой ситуации нет.

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

129

Глава 4. Параллелизм в операционных системах

гают разработчики систем с целью улучшения использования ресурсов в подобных обстоятельствах, заключается в том, чтобы разделять программу на несколько программных шагов, выполняемых относительно независимо друг от друга. Благодаря этому можно осуществлять выделение ресурсов для каждого шага программы, а не для целого процесса. Это позволяет уменьшить непроизводительное использование ресурсов, однако связано с увеличением накладных расходов на этапе проектирования прикладных программ, а также на этапе их выполнения. Систему, оказавшуюся в тупике, можно вывести из него, нарушив одно из условий его существования. При этом возможно, что несколько процессов частично или полностью потеряют результаты проделанной работы. Сложность восстановления системы после тупика обусловлена целым рядом факторов и может потребовать много работы. Тупики в современных системах обычно рассматриваются как достаточно редкая неприятность. В будущих системах тупиковые ситуации могут стать гораздо более критическим фактором, поскольку эти системы будут работать при гораздо более динамичном распределении ресурсов и большем количестве одновременно выполняемых процессов [1, 4, 6].

ГЛАВА 5.

Особенности организации различных

операционных систем

5.1. Концепции структурной организации операционных систем

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

К таким базовым концепциям относится, например, способ построения ядра системы: монолитное ядро или микроядерный подход [4, 5, 6]. Большинство ОС используют монолитное ядро, которое компонуется как одна программа, работающая в привилегированном режиме и использующая быстрые переходы с одной процедуры на другую, не требующие переключения из привилегированного режима в пользовательский и наоборот. Альтернативой является построение ОС на базе микроядра, работающего также в привилегированном режиме и выполняющего только минимум функций по управлению аппаратурой, в то время как функции ОС более высокого уровня выполняют специализированные компоненты ОС – серверы, работающие в пользовательском режиме. При таком построении ОС работает более медленно, так как часто выполняются переходы между привилегированным режимом и пользовательским, зато система получается более гибкой – ее функции можно наращивать, модифицировать или сужать, добавляя, модифицируя или исключая серверы пользовательского режима. Кроме того, серверы хорошо защищены друг от друга, как и любые пользовательские процессы.

При построении ОС на базе объектно-ориентированного подхода существует возможность использовать все его достоинства, хорошо зарекомендовавшие себя на уровне приложений внутри операционной системы. В числе этих достоинств можно назвать [4, 5, 6]:

• аккумуляцию удачных решений в форме стандартных

объектов;

<<< < Предыдущая 1 2 3 4 5 6 7 8 9 10 11 1213 / 1813 14 15 16 17 18 > Следующая >>>

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]