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

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

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

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

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

- введение линейной упорядоченности по типам ресурсов.

Все элементы этой стратегии имеют свои недостатки.

3.3.3. Обход тупиков

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

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

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

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

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

В будущих системах тупики станут в большей степени критическим фактором, т.к.

1) системы будут ориентированы на асинхронную параллельную работу;

2) будет реализовано преимущественно динамическое распределение ресурсов. Это может привести к тому, что в какой-то момент ресурсов может оказаться недостаточно;

3) увеличение количества ресурсов за счет включения в список ресурсов данных.

Пример тупика представлен на рис. 17.

Два процесса Пр1 и Пр2 разделяют два вида ресурсов р1 и р2, обращение к которым синхронизируется с помощью семафоров S1 и S2.

Рис. 17. Пример тупика

Соответствующие операции расставляются следующим образом:

Возможны три траектории выполнения процессов:

Траектория А - без проблем.

Траектория В - в точке Х Пр2 ждет освобождения р2.

Траектория С - дедлок в точке Z (Пр2 ждет р1, Пр1 ждет р2).

3.4.Средства обеспечения мультизадачности в защищенном режиме работы процессора Intel

Вам уже известно, что каждое приложение может состоять из нескольких параллельно или последовательно работающих задач. Квантование времени процессора выполняется на уровне задачи. По прерыванию таймера процессор переключается от одной задачи к другой, за счет чего и реализуется мультипрограммный режим работы. Для хранения контекста неактивной в настоящий момент задачи используется сегмент состояния задачи TSS (Task State Segment), ко- торый адресуется при помощи двухбайтового регистра ТR (Task Re- gister). Регистр содержит селектор дескриптора TSS в глобальной дескрипторной таблице.

Поле TYPE байта доступа дескриптора содержит значения 0х09 для неактивной задачи ("доступный" TSS) и 0х0A - для активной ("недоступный" TSS), то есть различаются значением бита 1 (отсчет от нуля). Переключение задачи в активное состояние осуществляется установкой этого бита.

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

регистры общего назначения EAX, EBX, ECX и EDX;

регистры-указатели ESP, EBP, ESI, EDI, EIP;

сегментные регистры ES, CS, SS, DS, FS, GS;

регистр флагов EFLAGS;

регистр LDTR с селектором дескриптора в GDT локальной дескрипторной таблицы, распределенной данной задаче;

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

База карты ввода-вывода	0			Т
0	LDTR
0	GS
0	FS
0	DS
0	SS
0	CS
0	ES
EDI
ESI
EBP
ESP
EBX
EDX
ECX
EAX
EFLAGS
EIP
CR3
0		SS2
ESP2
0		SS1
ESP1
0		SS0
ESP0
0			LINK

LINK предназначено для ссылки на TSS вызвавшей задачи при вложенном вызове задач. Здесь хранится селектор TSS, записанный командой CALL.

TSS содержит указатели на стеки для 0, 1 и 2-го приоритетных колец, соответственно SS0:ESP0, SS1:ESP1 и SS2:ESP2. Эти поля используются при межсегментных вызовах через вентили. Для каждого кольца защиты процессор назначает отдельные стеки. Когда задача вызывает функцию из другого кольца через вентиль вызова, процессор загружает указатель стека SS:ESP адресом нового стека, взятого из соответствующего поля TSS. В новый стек копируется адрес вершины старого стека, параметры функции, количество которых задано в вентиле вызова и адрес возврата. Таким образом, при вызове привилегированного модуля через вентиль вызова менее привилегированная программа не может передать в стеке больше параметров, чем это определено операционной системой для этого модуля. Включение адресов стеков в TSS позволяет разделить стеки задач и обеспечивает их автоматическое переключение при переключении задач. При отладке программы устанавливается в 1 бит Т, в результате чего при переключении на задачу возникает отладочное исключение (0х01), которое может быть использовано отладчиком.

База карты ввода-вывода указывает 16-тиразрядное смещение начала битовой карты ввода-вывода (БКВВ) относительно TSS. Битовая карта ввода-вывода определяет порты, которые может использовать задача. Если задача обратится к несанкционированному порту ввода-вывода, произойдет исключение. Это необходимо для безопасной работы системы. Предел TSS должен определяться с учетом карты ввода-вывода. Каждый бит в карте соответствует адресу байта порта ввода-вывода. БКВВ завершается байтом 0хFF. При выполнении операций с портами процессор проверяет все биты, соответствующие адресу порта. Если какой-либо бит установлен в 1, генерируется исключение. Проверка битовой карты не выполняется, если флаг IOPL больше или равен уровню привилегий. Установка базы карты ввода-вывода большей или равной пределу TSS позволяет полностью запретить обращение к портам. Любая команда ввода-вывода приведет к генерации исключения.