ОСС / 7
.pdf
7. Прерывания. Супервизоры. Захваты.
Асинхронная замена контекста может осуществляться исключениями (exceptions), что отражено на Ошибка: источник перёкрестной ссылки не найден. Под исключениями понимают прерывания, вызванные внутренними событиями. Чаще всего эти события связаны с ошибками, например, деление на нуль. Говоря другими словами, замена контекста, связанная с исключениями, носит специфический характер и далее рассматриваться не будет.
Рис. 3.1
Способы организации прерываний. В компьютерах 4 –ого поколения (к ним относятся и ПК) связь между устройствами осуществляется по общей шине (ОШ), которая может иметь достаточно сложную структуру. В отличии от машин 3-ого поколения центральные и периферийные устройства подсоединяются к ОШ на равноправной основе. При этом, если не обращать внимания на некоторые нюансы, к общей шине, которую по другому называют магистральным каналом (МК) могут быть подсоедены два устройства (как правило одно из них - процеессор). Если ПУ, есть «что сказать» он вызывает прерывание и «запрашивает связь» у процессора. В избежании аварийной ситуации прерывания, вызываемые ПУ, имеют разные приоритеты и одновременный запрос от нескольких устройств не вызывает «головной боли» у процессора - он реагирует на самый важный, откладывая другие на потом. В процессе
технического прогресса этот стройный подход претерпел некоторые изменения. Процессор через «задние двери» «доверительно» обменивается информацией с кэш памятью, специальный процессор ДМА (см. раньше), имея «склонность» к самостоятельной работе, организует некоторый намек на параллеьную работу и т. д. Тем не менее роль прерываний в организации взимодействия центральных устройств с переферийными за последние десятилетия осталась неизменной и носит исключительно важный характер. Представляет интерес, что основная концепция семейств машин IBM PC связанна с применением прерываний для обеспечения преемственности. При таком подходе различие в машинных кодах спрятано в обработчиках прерываний, а на пользовательском уровне протокол вызова этих прерываний одинаков для всех процеесоров типа i80x86 (работа по протоколу называется программированием на среднем уровне). Справедливости ради, следует отметить, что у этого подхода есть и существенный недостаток – протоколы, которые были разработаны для 16 –разрядных процессоров, пришлось перенести и на 32 - разрядные процессоры со всеми вытекающими из этого неприятностями. В частности реальный режим, который является исходным для машин указанного типа в концептуальном плане далеко не самый оптимальный для 32 - разрядных процессоров. Тем не менее, этот принцип служил на благо массовому пользователю до тех пор, пока не стала все в большой степени проявляться тенденция «степени прятать некоторые аспекты ОС (и следовательно, ограничиваит прямой доступ к аппаратным средствам) от пользователя». Разумеется, это повышает бесопасность системы, но с точки зрения владельца персонального компьютера является нонсенсом, так как отнимает у него законное право «разобрать» свою собственную систему и персональный компьютер на составные части.
Наряду с аппаратными прерываниями существуют программные прерывания, которые по сути вызываются как обычные подпрограммы, но упакованы в форму, удобную для дополнения операционной системы. Реализации прерываний в разных ОС различны, но их условно можно разделить на две группы.
Для одной группы характерно хранение обработчиков прерываний в специальном пространстве памяти (например ядро Wind ОС Vx Works), и как следствие укороченный контекст доступа к обработчику (Рис. 3 .2). Ключевое слово interrupt служит основанием для отсылки по адресу @interrupt, а по номеру прерывания определяется смещение до нужного обработчика прерывания.
Зона памяти в плоском
@ interrupt пространстве для размещения обработчиков прерывания
Рис. 3.2
ВОС другого более многочисленного типа (MS DOS, различные версии Windows
ит.д.) обработчики прерываний вызываются по полному контексту, что позволяет хранить их в различных участках памяти (Рис. 3 .3). Этот рисунок соответствует работе прерываний в MS DOS (примерно такие же или аналогичные схемы имеют место для ОС, в которых обработчик прерывания имеет полный контекст). На младших адресах памяти находятся таблица 256 –и векторов прерывания, каждый из которых занимает 4 байта. По номеру прерывания можно непосредственно добраться до соответствующей ячейки и считать из неё адрес соответствующего обработчика и запустить его. Этого же эффекта можно добиться командной строкой int N, где N- номер прерывания. Прерывания можно характеризовать по разным шкалам.
Во - первых, аппаратные и программные (см. раньше). Все аппаратные прерывания являются прерываниями BIOS/ С точки зрения их использования они отличаются только тем, команду int N для программных прерываний нужно набирать в явном виде, а при аппаратных прерываниях это осущесвляется в неявном виде.
Во – вторых , прерывания могут быть документированными (т. е. строго работающие по протоколу), недокументированные (среди них есть даже поддерживающие многозадачность, но нужный результат их работы не гарантируется) и свободные, которые пользователь может использовать в своих целях. Впрочем другие прерывания можно тоже переписать заново или перекрыть (т. е. к существующим операциям обработчика добавить свои). Так же можно в обработчике прнрывания вызывать другое прерывание (зта процедура может ограничиваться только соображениями реентерабильности). Такая демократичность не только восхищает, но и вызывает желание использовать её в собственных разработках (см. раздел 4).
Для управления аппаратными прерываниями в процессорах семейства i80x86 в
качестве контроллера прерываний (PIC-portable interrupt controller) используются две микросхемы 8259 (основная и вспомогательная). Каждая микросхема поддерживает 8 уровней прерываний и имеет по три порта для обмена данными с процессором.
Контроллер прерываний через порт 20h устанавливает приоритет равным приоритету прерывания, обрабатываемого в данный момент. Это позволяет отложить установку прерывания с более низким приоритетом и дать «зеленую улицу» прерыванию с более высоким значением приоритета. Однако, после окончания работы соответствующего прерывания приоритет автоматически не сбрасывается. Если не принять соответствующие меры, то система может быть заблокирована. При написении собственного обработчика аппаратного прерывания эту проблему легко можно уладить, если к конце обработчика прерывания внести следующие коды:
mov al, 20h
out 20h, al ,
которые сбрасывают установленный приоритет. То, что засылаемое число и номер порта одинаковы, не имеет глубокого смысла, а является простым совпадением.
Увеличение адресов памяти
Транзитная область памяти
Обработчик пользов. прерывания |
|
Область памяти DOS |
|
Обработчик прерывания DOS |
|
Область памяти BIOS |
|
Обработчик прерывания BIOS |
1 кб |
|
|
@ int N1(пользов. прерывание) |
|
@ int N2(прерывание DOS) |
|
@ int N3(прерывание BIOS) |
0 |
|
|
Рис. 3.3 |
|
Запрещение прерываний. При программировании может возникать необходимость сделать некоторую последовательность кодов неделимой, ибо частично выполненный код после прерывания может привести к ошибке. В этом случае требуется запретить прерывания на выполение всей указаннойпоследовательности кодов. Это можно сделать с помощью операторов CLI и STI. Эти операторы соответственно устанавливают и сбрасывают флаг запрета прерывания в флаговом регистре:
CLI
неделимая последовательность кодов;
STI
Если нужно осуществить более деликатную операцию – запретить только один уровень прерывания, то следует использовать маскирование, которая осуществляется через порт 21h контроллера прерывания. Для этого в него нужно заслать байт с установленным битом запрещенного уровня прерывания. Например, если нужно сделать компьютор нечуствительным к клаклавиатуре, прерывание от которой имеет значение приоритета 1, следует установить первый бит:
mov al, 00000010b
out 21h, al
Обратная операция - демаскирование производится засылкой в порт 21h нулевого значения:
mov al, 00
out 21h, al
Теперь штатный порядок работы с аппаратными прерываниями восстановится.
Понятие о сигналах. Сигнал – это прерывание, связанное с определенной причиной. Первоначально сигналы носили сугубо системный характер. Далее этот инструмент был использован в ОС UNIX BSD для обмена сообщений между процессами и между процессами и системой. После получения сигнала процесс изменяет ход выполнения. В частности, использование специального сигнала kill( ) является одним из способов корректного завершения работы процесса. Правда процессору оставлена возможность отложить «приговор» , в частности, если процесс находится в критическом участке.
В операционной системе РВ Vx Works введены дополнения, которые удачно вписываются в концепции программирования в реальном времени. В частности, процесс может посылать сигнал сам себе (своеобразный будильник). После этого он может «заснуть» и проснуться только тогда, когда произойдет событие, на которое настроен сигнал инициализированный процессом. Другое новшество дает возможным наладить продуктивное взаимодействме между классом событий и классом обработчиков – система выделяет 31 сигнал, каждый из которых разработчик программ, может настроить на определенное событие.
Вызов супервизора. Супервизор -это часть управляющей программы, координирующая распределение ресурсов вычислительной системы. Примерами вызовов супервизора в графической опрерационной системе являются команды, вызываемые нажатием мыши (или нажатием на «горячие клвиши») на определенный пункт меню (свернуть или закрыть активную программу, открыть новую, вызвать справочник и т. д.). Как обычно бывает, при использовании в качестве посредника системы, при вызове некоторых функций и режимов осуществляется проверка прав доступа. Контекст активного процесса определяется в зоне памяти, не доступной для пользователя, что отчасти повышает безопасность системы.
Вообще, вызов ресурсов через системного посредника улучшает «управляемость», так как система «знает» ситуацию и адекватно на неё реагирует. При непосредственное же обращении процесса к требуемому ресурсу, даже если оно представляется,на первый взгляд правильным, может привести привести к зависанию системы
Захват
Представим, что на оживленном перекрестке сломался светофор. Автомобили, предоставленные сами себе, решают собственный проблемы, не обращая никакого внимания на соседей. Не надо обладать богатым воображением или большим жизненным опытом, чтобы предсказать результат, который последует после такого рода деятельности. Участники (и одновременно жертвы), попавшие в эту тупиковую ситуацию, наверное многое бы дали за возможность вернуться на несколько минут в прошлое и распорядиться этим бонусным временем совсем иначе.
Тупиковая ситуация или взаимоблокировка могут иметь место и в вычислительных системах. Отличие заключается только в том, что происходит это не в результате какой то поломки, а при работе в вполне штатном режиме. Правда, для этого нужно, чтобы:
процессам потребовалось для одновременной работы не менее двух ресурсов;
возникли определенные фосмажорные обстоятельства.
Пусть Процессу 1 и Процессу 2 одновременно потребовался критический участок, в котором осуществляется работа с ресурсами. Например, двум процессам нужно отсканированный документ распечатать на принтере. Для осуществления этого замысла каждому из них нужно захватить оба ресурса.
При этом программный код написан таким образом (см. Ошибка: источник перёкрестной ссылки не найден), что в первом процессе захватывается сначала семафор первого, ресурса, а затем второго. Во втором процессе захваты семафоров осуществляется в обратном порядке. Пусть теперь первый процесс успевает захватить первый семафор, после чего происходит асинхронное переключение контекста, и он с закрепленным за собой первым ресурсом встает в конец очереди готовых. Став активным, второй процесс через функцию ЗахватСем2() захватывает второй ресурс. Последующая попытка этого процесса захватить первый ресурс заканчивается неудачей и он, по всем правилам, встает в очередь первого семафора Процесс 1, перешедший в активное состояние и, успев только вызвать функцию ЗахватСем2(), моментально отправляется в очередь второго семафора. Ловушка захлопнулась. Если не предпринимать никаких специальных мер, «горемыкам» придется провести время в указанных очередях до ближайшей перезагрузки системы. Ситуация может стать критической не только для этих процессов, но и для всей системы в целом, если захваченные и неработающие ресурсы пользуются популярностью у других процессов. В этом случае перезагрузка системы станет необходимой в самое ближайшее время.
