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

Глава 4. Процессы и потоки

2004-12-15

Продолжение

Диспетчеризация и приоритезация прерываний в ОС

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

Операционная система не может терять контроль над ходом выполне-ния системных процедур, вызываемых по прерываниям. Она должна упоря-дочивать их во времени так же, как планировщик упорядочивает многочис-ленные пользовательские потоки. Кроме того, сам планировщик потоков яв-ляется системной процедурой, вызываемой по прерываниям (аппаратным - от таймера или контроллера устройства ввода-вывода, или программным - от приложения или модуля ОС). Поэтому правильное планирование процедур, вызываемых по прерываниям, является необходимым условием правильного планирования пользовательских потоков. В противном случае в системе мо-гут возникать, например, такие ситуации, когда операционная система будет длительное время заниматься не требующей мгновенной реакции задачей управления стримером, архивирующим данные, в то время, когда высокоско-ростной диск будет простаивать и тормозить работу многочисленных прило-жений, обменивающихся данными с этим диском. Еще один пример такой ситуации иллюстрирует рис. 4.12. В данном случае обработчик прерываний принтера блокирует на длительное время обработку прерывания от таймера, в результате чего системное время на некоторое время "замирает" и поток 2, критически важный для пользователя, не получает управление в запланиро-ванное время. Остроту проблемы несколько смягчает то обстоятельство, что во многих случаях обработка прерывания связана с выполнением всего не-скольких операций ввода-вывода и поэтому имеет очень небольшую продолжительность. Тем не менее ОС всегда должна контролировать ситуацию и выполнять критичную работу вовремя, а не полагаться на волю случая.

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

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

ПРИМЕЧАНИЕ. Приоритет обработчиков прерываний не совпадает в общем случае с приоритетом потоков, выполняемых в обычной последовательности, определяемой пла-нировщиком потоков. По отношению к обработчикам прерываний любой поток, который назначен на выполнение планировщиком, имеет самый низкий приоритет, так что любой запрос на прерывание всегда может прервать выполнение этого потока.

Функции централизованного диспетчера прерываний на примере Windows NT

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

Для исключения зависимости от аппаратной платформы в некоторых ОС вводится собственная программная система приоритетов прерываний. Примером такой ОС может служить 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). Это явля-ется некоторым допущением, так как код потоков начинает выполняться процессором не в результате запроса на прерывание, но это допущение хо-рошо работает, поскольку позволяет любому "настоящему" запросу преры-вать код обычного потока.

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

Прерывания от внешних устройств занимают промежуточные уровни IRQL. Конкретное соотношение между приоритетами внешних устройств определяется приоритетами, задаваемыми аппаратной платформой, например уровнем IRQ шины PCI, назначенным устройству.

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

В системе очередей диспетчера прерываний несколько очередей отве-дено для обслуживания отложенных программных прерываний.

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

Этот уровень приоритета называется диспетчерским, потому что именно в эту очередь помещаются программные запросы, вызывающие дис-петчер потоков. Часто при обработке высокоприоритетных прерываний воз-никает ситуация, требующая перепланирования потоков. Например, при об-работке очередного прерывания от таймера нужно проверить, не исчерпан ли квант, выделенный текущему потоку. Другим примером может служить об-работка прерывания от контроллера диска после завершения дисковой опе-рации, которую могут ждать несколько потоков. Во всех таких ситуациях в Windows NT планировщик/диспетчер вызывается высокоуровневыми проце-дурами ядра не прямо посредством вызова процедуры, а косвенно, с помо-щью программного прерывания. Это дает возможность отделить короткую, но требующую быстрой реакции системы процедуру обслуживания высоко-приоритетного прерывания (например, наращивание системных часов) от менее критичной операции перепланирования пользовательских потоков. Прямой вызов планировщика/диспетчера потоков такой возможности бы не дал, и критичные запросы прерывания от контроллеров устройств ввода-вывода вынуждены были бы ждать, пока отработает планировщик. При этом планировщик, возможно, выбрал бы для выполнения другой поток, если бы работал после процедур обслуживания аппаратных прерываний, так как он получил бы свежие сведения о завершении некоторых операций ввода-вывода. Помещение вызова планировщика потоков в очередь позволяет вы-полнять его только в тех ситуациях, когда в системе отсутствуют ожидающие аппаратные запросы прерываний.

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

Второе название диспетчерского уровня, DPC, являясь аббревиатурой от Deffered Procedure Call (вызов отложенной процедуры), говорит о том, что на этом уровне ожидают своей очереди отложенные вызовы и других проце-дур ОС, а не только планировщика/диспетчера. Процедуры ОС могут вызы-вать друг друга и непосредственно, но при многослойном построении ядра существуют более и менее приоритетные процедуры, и вызов менее приори-тетных процедур из более приоритетных с помощью механизма программ-ных прерываний позволяет, как и в случае с планировщиком, упорядочить во времени их выполнение, что оптимизирует работу ОС в целом. Примером процедур ОС, работающих на высоком приоритетном уровне, являются те части драйверов устройств ввода-вывода, которые выполняют короткие, но критичные ко времени реакции действия. В то же время существуют и другие части драйверов, которые выполняют менее срочную, но более объемную ра-боту . В Windows NT такие части драйверов оформляют как процедуры, вы-зываемые с помощью программных прерываний уровня "диспетчер-ский/DPC" (DPC-процедуры), а само программное прерывание выполняет критичная часть драйвера. Естественно, существуют и другие модули ОС, оформляемые подобным образом.

Описанная программная реализация приоритетного обслуживания прерываний приводит к однотипной работе ОС Windows NT на различных аппаратных платформах, что упрощает логику работы ОС и ее перенос на новые платформы. Отрицательным следствием такого централизованного подхода является некоторое замедление обработки прерываний, так как вме-сто непосредственной передачи управления драйверу устройства или обра-ботчику исключений выполняется вызов некоего посредника - диспетчера прерываний. В ОС семейства UNIX принят похожий, но менее централизо-ванный подход к ведению и обработке очередей прерываний. Вместо единого диспетчера прерываний его функции выполняют процедуры, обслуживаю-щие каждый приоритетный класс прерываний. Тем не менее, общий подход к упорядочиванию обработки прерываний за счет их многоуровневой приори-тезации и ведения системы очередей присутствует практически во всех со-временных операционных системах.

Продолжение следует...