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

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

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

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

¹ В операционных системах семейства Unix эти части называют соответственно верхними половина­ми (top half) и нижними половинами (bottom half) обработчика прерываний.

Процедуры обработки прерываний и текущий процесс

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

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

Хороший пример того, что не бывает правил без исключений, предоставляет нам семейство ОС Windows NT. В этих ОС существуют процедуры обслужива­ния прерываний, которые всегда выполняются в контексте определенного про­цесса. Это процедуры, вызываемые с помощью программного прерывания АРС (Asynchronous Procedure Call — асинхронный вызов процедуры). Для них в дис­петчере прерываний предусмотрен свой уровень приоритета IRQL, выше уров­ня для обычного кода, но ниже уровня DPC. Эти процедуры могут прервать те­кущий код и выполниться при соблюдении двух условий: текущий код имеет низший уровень приоритета (то есть выполняется обычный код), текущим процессом является вполне определенный процесс, описатель которого был за­дан в запросе на прерывание для данной АРС-процедуры. АРС-процедуры мо­гут пользоваться ресурсами текущего процесса, и, собственно, для этого они и были введены. Основное назначение АРС-процедур — перемещение данных, полученных драйвером от какого-либо устройства ввода-вывода, из памяти