ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 18.06.2021
Просмотров: 1446
Скачиваний: 9
Для исключения зависимости от аппаратной платформы в некоторых ОС вводится собственная программная система приоритетов прерываний. Примером такой ОС может служить Windows NT.
Диспетчер прерываний Windows NT (так называемый Trap Handler) работает с программной моделью прерываний, единой для всех аппаратных платформ, поддерживаемых Windows NT. Все источники прерываний (аппаратных и программных, а также некоторых важных для системы исключений, например исключения по ошибке шины) делятся на несколько классов, и каждому классу присваивается уровень запроса прерывания — Interrupt Request Level, IRQL Этот уровень и представляет приоритет данного класса. Операционная система программным способом поддерживает внутреннюю переменную, называемую IRQL выполняемого процессором кода, которая по назначению соответствует уровню прерывания процессора. Если процессор, на котором работает ОС, поддерживает такую переменную, то она используется и IRQL выполняемого кода отображается на нее, в противном случае соответствующие функции процессора эмулируются программно.
Общая схема планирования обработки прерываний выглядит в Windows NT следующим образом. При поступлении в процессор сигнала запроса на прерывание/исключение вызывается диспетчер прерываний, который запоминает информацию об источнике прерывания и анализирует его приоритет. Если приоритет запроса ниже или равен IRQL прерванного кода, то обслуживание этого запроса откладывается и данные о запросе помещаются в соответствующую очередь запросов, после чего происходит быстрый возврат к прерванному обработчику прерываний. По завершении обработки высокоприоритетного прерывания управление возвращается диспетчеру прерываний, который просматривает очереди отложенных прерываний и выбирает из них наиболее приоритетное. При этом уровень IRQL снижается до уровня выбранного прерывания.
Если же запрос имеет более высокий приоритет, чем IRQL текущего кода, то текущий обработчик прерываний вытесняется и ставится в очередь, соответствующую его значению IRQL, а управление передается новому обработчику в соответствии с IRQL запроса. После этого уровень IRQL процессора делается равным уровню IRQL принятого на выполнение запроса.
Таким образом, запрос на прерывание принимается диспетчером прерываний всегда независимо от текущего уровня IRQL выполняемого кода, но диспетчер прерываний не передает его на обработку соответствующей процедуре обработки прерываний, а помещает в программную очередь запросов, если в данный момент выполняется более приоритетная процедура обработки прерываний. Операционная система имеет полный контроль над ситуацией, не позволяя контроллерам устройств ввода-вывода принимать решения о ходе вычислительного процесса.
В Windows NT низший уровень IRQL соответствует обычным потокам, назначаемым на выполнение диспетчером потоков (рис. 4.13). Это является некоторым допущением, так как код потоков начинает выполняться процессором не в результате запроса на прерывание, но это допущение хорошо работает, поскольку позволяет любому «настоящему» запросу прерывать код обычного потока.
Рис. 4.13. Диспетчеризация прерываний в Windows NT
Высший уровень в иерархии IRQL отводится таким важным событиям, как исключение по ошибке шины и другим тяжелым аппаратным сбоям, далее располагаются запрос на прерывание по сбою питания и запрос на межпроцессорное прерывание.
Прерывания от внешних устройств занимают промежуточные уровни IRQL. Конкретное соотношение между приоритетами внешних устройств определяется приоритетами, задаваемыми аппаратной платформой, например уровнем IRQ шины PCI, назначенным устройству.
Особую роль в работе вычислительной системы играет системный таймер: на основании его прерываний обновляются системные часы, определяющие очередной момент вызова планировщика потоков, момент выдачи управляющего воздействия потоком реального времени и многое другое. Ввиду важности немедленной обработки прерываний от таймера, ему в Windows NT дан весьма высокий уровень приоритета — более высокий, чем уровень любого устройства ввода-вывода.
В системе очередей диспетчера прерываний несколько очередей отведено для обслуживания отложенных программных прерываний.
Программные прерывания, обслуживающие системные вызовы от приложений, выполняются с низшим уровнем приоритета, что соответствует концепции продолжения одного и того же процесса, но только в системной фазе, при выполнении системного вызова. А вот для программных прерываний, исходящих от модулей ядра ОС, отводится более высокий уровень запросов, имеющий двойное название «диспетчерский/DPO.
Этот уровень приоритета называется диспетчерским, потому что именно в эту очередь помещаются программные запросы, вызывающие диспетчер потоков. Часто при обработке высокоприоритетных прерываний возникает ситуация, требующая перепланирования потоков. Например, при обработке очередного прерывания от таймера нужно проверить, не исчерпан ли квант, выделенный текущему потоку. Другим примером может служить обработка прерывания от контроллера диска после завершения дисковой операции, которую могут ждать несколько потоков. Во всех таких ситуациях в Windows NT планировщик/диспетчер вызывается высокоуровневыми процедурами ядра не прямо посредством вызова процедуры, а косвенно, с помощью программного прерывания. Это дает возможность отделить короткую, но требующую быстрой реакции системы процедуру обслуживания высокоприоритетного прерывания (например, наращивание системных часов) от менее критичной операции перепланирования пользовательских потоков. Прямой вызов планировщика/диспетчера потоков такой возможности бы не дал, и критичные запросы прерывания от контроллеров устройств ввода-вывода вынуждены были бы ждать, пока отработает планировщик. При этом планировщик, возможно, выбрал бы для выполнения другой поток, если бы работал после процедур обслуживания аппаратных прерываний, так как он получил бы свежие сведения о завершении некоторых операций ввода-вывода. Помещение вызова планировщика потоков в очередь позволяет выполнять его только в тех ситуациях, когда в системе отсутствуют ожидающие аппаратные запросы прерываний.
Наличие отдельного уровня для планировщика/диспетчера потоков не означает того, что он всегда вызывается с помощью программных прерываний. В тех случаях, когда он вызывается из кода, имеющего низкий уровень запроса на прерывание (если он выполняется, значит, высокоприоритетные запросы на прерывание отсутствуют), планировщик может быть вызван быстрее путем непосредственного внутрисегментного вызова процедуры. Например, системному вызову, переводящему поток по собственному желанию в состояние ожидания, нет смысла вызывать планировщик потоков по программному прерыванию.
Второе название диспетчерского уровня, DPC, являясь аббревиатурой от Deffered Procedure Call (вызов отложенной процедуры), говорит о том, что на этом уровне ожидают своей очереди отложенные вызовы и других процедур ОС, а не только планировщика/диспетчера. Процедуры ОС могут вызывать друг друга и непосредственно, но при многослойном построении ядра существуют более и менее приоритетные процедуры, и вызов менее приоритетных процедур из более приоритетных с помощью механизма программных прерываний позволяет, как и в случае с планировщиком, упорядочить во времени их выполнение, что оптимизирует работу ОС в целом. Примером процедур ОС, работающих на высоком приоритетном уровне, являются те части драйверов устройств ввода-вывода, которые выполняют короткие, но критичные ко времени реакции действия. В то же время существуют и другие части драйверов, которые выполняют менее срочную, но более объемную работу1. В Windows NT такие части драйверов оформляют как процедуры, вызываемые с помощью программных прерываний уровня «диспетчерский/DPC» (ВРОпроцедуры), а само программное прерывание выполняет критичная часть драйвера. Естественно, существуют и другие модули ОС, оформляемые подобным образом.
1 В операционных системах семейства UNIX эти части называют соответственно верхними половинами (top half) и нижними половинами (bottom half) обработчика прерываний.
Описанная программная реализация приоритетного обслуживания прерываний приводит к однотипной работе ОС Windows NT на различных аппаратных платформах, что упрощает логику работы ОС и ее перенос на новые платформы. Отрицательным следствием такого централизованного подхода является некоторое замедление обработки прерываний, так как вместо непосредственной передачи управления драйверу устройства или обработчику исключений выполняется вызов некоего посредника — диспетчера прерываний. В ОС семейства UNIX принят похожий, но менее централизованный подход к ведению и обработке очередей прерываний. Вместо единого диспетчера прерываний его функции выполняют процедуры, обслуживающие каждый приоритетный класс прерываний. Тем не менее, общий подход к упорядочиванию обработки прерываний за счет их многоуровневой приоритезации и ведения системы очередей присутствует практически во всех современных операционных системах.
Процедуры обработки прерываний и текущий процесс
Важной особенностью процедур, выполняемых по запросам прерываний, является то, что они выполняют работу, чаще всего никак не связанную с текущим процессом. Например, драйвер диска может получить управление после того, как контроллер диска записал в соответствующие сектора информацию, полученную от процесса А, но этот момент времени, скорее всего, не совпадет с периодом очередной итерации выполнения процесса А или его потока. В наиболее типичном случае процесс А будет находиться в состоянии ожидания завершения операции ввода-вывода (при синхронном режиме выполнения этой операции) и драйвер диска прервет какой-либо другой процесс, например процесс В. В Windows NT процедуры, вызываемые как DPC, также могут работать в контексте процесса, отличающегося от того, для которого они выполняют свои функции. В некоторых случаях вообще трудно однозначно определить, для какого процесса выполняет работу тот или иной программный модуль ОС, например планировщик потоков. Поэтому для такого рода процедур вводятся ограничения — они не имеют права использовать ресурсы (память, открытые файлы и т. п.), с которыми работает текущий процесс, или же от имени этого процесса запрашивать выделение дополнительных ресурсов. Процедуры обработки прерываний работают с ресурсами, которые были выделены им при инициализации соответствующего драйвера или инициализации самой операционной системы. Эти ресурсы принадлежат операционной системе, а не конкретному процессу. В частности, память выделяется драйверам из системной области, то есть той области, на которую отображаются сегменты из общей части виртуального адресного пространства всех процессов. Поэтому обычно говорят, что процедуры обработки прерываний работают вне контекста процесса. Поскольку все подобные процедуры являются частью операционной системы, ответственность за соблюдение этих ограничений несет системный программист. Заставить свои модули выполнять эти ограничения ОС не может.
Хороший пример того, что не бывает правил без исключений, предоставляет нам ОС Windows NT. В ней существуют процедуры обработки прерываний, которые выполняются всегда в контексте определенного процесса. Это процедуры, вызываемые с помощью программного прерывания АРС (Asynchronous Procedure Call, вызов асинхронной процедуры). Для них в диспетчере прерываний предусмотрен свой уровень приоритета IRQL, выше уровня для обычного кода, но ниже уровня DPC. Эти процедуры могут прервать текущий код и выполниться при соблюдении двух условий: текущий код имеет низший уровень приоритета (то есть выполняется обычный код), текущим процессом является вполне определенный процесс, описатель которого был задан в запросе на прерывание для данной процедуры АРС. Процедуры АРС могут пользоваться ресурсами текущего процесса, и, собственно, для этого они и были введены. Основное назначение АРС-процедур — перемещение данных, полученных драйвером от какого-либо устройства ввода-вывода, из памяти системной области памяти, куда они помещаются после считывания из регистров контроллера этого устройства, в индивидуальную часть адресного пространства процесса, запросившего операцию ввода-вывода. Такое действие постоянно выполняется системой ввода-вывода, и для его реализации были введены такие специфические процедуры обработки прерываний, как АРС.
Диспетчеризация прерываний является важной функцией ОС, и эта функция реализована практически во всех мультипрограммных операционных системах. Можно заметить, что в общем случае в операционной системе реализуется двухуровневый механизм планирования работ. Верхний уровень планирования выполняется диспетчером прерываний, который распределяет процессорное время между потоком поступающих запросов на прерывания различных типов — внешних, внутренних и программных. Оставшееся процессорное время распределяется другим диспетчером — диспетчером потоков, на основании дисциплин квантования и других, рассмотренных выше.
Системные вызовы
Системный вызов позволяет приложению обратиться к операционной системе с просьбой выполнить то или иное действие, оформленное как процедура (или набор процедур) кодового сегмента ОС. Для прикладного программиста операционная система выглядит как некая библиотека, предоставляющая некоторый набор полезных функций, с помощью которых можно упростить прикладную программу или выполнить действия, запрещенные в пользовательском режиме, например обмен данными с устройством ввода-вывода.
Реализация системных вызовов должна удовлетворять следующим требованиям:
обеспечивать переключение в привилегированный режим;
обладать высокой скоростью вызова процедур ОС;
обеспечивать по возможности единообразное обращение к системным вызовам для всех аппаратных платформ, на которых работает ОС;
допускать легкое расширение набора системных вызовов;
обеспечивать контроль со стороны ОС за корректным использованием системных вызовов.
Первое требование для большинства аппаратных платформ может быть выполнено только с помощью механизма программных прерываний. Поэтому будем считать, что остальные требования нужно обеспечить именно для такой реализации системных вызовов. Как это обычно бывает, некоторые из этих требований взаимно противоречивы.
Для обеспечения высокой скорости было бы полезно использовать векторные свойства системы программных прерываний, имеющиеся во многих процессорах, то есть закрепить за каждым системным вызовом определенное значение вектора. Приложение при таком способе вызова непосредственно указывает в аргументе запроса значение вектора, после чего управление немедленно передается требуемой процедуре операционной системы (рис. 4.14, а). Однако этот децентрализованный способ передачи управления привязан к особенностям аппаратной платформы, а также не позволяет операционной системе легко модифицировать набор системных вызовов и контролировать их использование. Например, в процессоре Pentium количество системных вызовов определяется количеством векторов прерываний, выделенных для этой цели из общего пула в 256 элементов (часть которых используется под аппаратные прерывания и обработку исключений). Добавление нового системного вызова требует от системного программиста тщательного поиска свободного элемента в таблице прерываний, которого к тому же на каком-то этапе развития ОС может и не оказаться.