<<
>>

Исполнительный уровень

Как показано на рис. 11.4, ниже уровня ядра NTOS находится исполнительная система. Этот исполнительный уровень написан на языке С, он в основном не зависим от архитектуры (примечательное исключение — диспетчер памяти) и был с минимальными усилиями перенесен на новые процессоры (MIPS, x86, PowerPC, Alpha, IA64, x64 и ARM).
Исполнительный уровень содержит несколько различных компонентов, все они работают при помощи абстракций управления, предоставляемых уровнем ядра.

Все компоненты разделены на внутренние и внешние структуры данных и интерфейсы. Внутренние аспекты всех компонентов скрыты и используются только внутри самого компонента, в то время как внешние аспекты доступны всем остальным компонентам исполнительного уровня. Некоторое подмножество внешних интерфейсов экспортируется из ntoskrnl.exe, и драйверы устройств могут привязаться к ним так, как будто исполнительный уровень является библиотекой. Компания Microsoft называет многие компоненты исполнительного уровня диспетчерами, поскольку каждый из них отвечает за управление каким-то аспектом работы (вводом-выводом, памятью, процессами, объектами и т.

д.).

Как и в большинстве операционных систем, большая часть функциональности исполнительного уровня Windows подобна библиотечному коду, за исключением того, что он выполняется в режиме ядра, так что его структуры данных могут использоваться совместно и защищаться от доступа кода пользовательского режима, поэтому он может обращаться к состоянию режима ядра (например, к управляющим регистрам блока управления памятью — MMU). Но в остальном исполнительный уровень просто выполняет функции операционной системы от имени вызвавшей их стороны и таким образом работает в потоке вызвавшей стороны.

Когда какая-либо из функций исполнительного уровня блокируется в ожидании синхронизации с другими потоками, то поток пользовательского режима также блокируется.

Это имеет смысл в том случае, когда работа выполняется от имени конкретного потока пользовательского режима, но может быть несправедливым при выполнении такой работы, которая связана с обычными «хозяйственными» задачами. Для того чтобы предотвратить «кражу» текущего потока в том случае, когда исполнительный уровень определяет, что нужно выполнить некоторую «хозяйственную» работу, при загрузке системы создается несколько потоков режима ядра (которые распределяются конкретным задачам, таким как обеспечение записи на диск модифицированных страниц).

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

Диспетчер объектов (object manager) управляет большинством интересных объектов режима ядра, используемых на исполнительном уровне. Это процессы, потоки, файлы, семафоры, устройства и драйверы ввода-вывода, таймеры и многое другое. Как уже описывалось, объекты режима ядра фактически являются просто структурами данных, которые размещаются и используются ядром. В Windows структуры данных ядра имеют много общего, так что очень полезно управлять ими неким унифицированным способом.

Диспетчер объектов предоставляет следующие средства: управление размещением и освобождением памяти для объектов, учет квот, поддержка доступа к объектам при помощи описателей, подсчет ссылок на указатели в режиме ядра и ссылок на описатели, именование объектов в пространстве имен NT, предоставление расширяемого механизма для управления жизненным циклом любого объекта. Те структуры данных ядра, которым нужны эти средства, управляются диспетчером объектов.

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

Это не тип в объектно-ориентированном смысле — это просто коллекция параметров, указываемых при создании типа объекта. Для создания нового типа компонент исполнительного уровня просто вызывает API диспетчера объектов. Объекты занимают настолько важное место в функционировании Windows, что мы будем обсуждать диспетчер объектов в следующем разделе более подробно.

Диспетчер ввода-вывода (I/O manger) предоставляет инфраструктуру для реализации драйверов устройств ввода-вывода и обеспечивает несколько служб исполнительного уровня для конфигурирования устройств, доступа к ним и выполнения с ними операций. В Windows драйверы устройств не только управляют физическими устройствами, они также обеспечивают расширяемость операционной системы. Многие функции, которые в других системах скомпилированы в состав ядра, в Windwos динамически загружаются и связываются (в том числе стеки сетевых протоколов и файловые системы).

В новых версиях Windows имеется гораздо большая поддержка работы драйверов устройств в пользовательском режиме (для новых драйверов устройств эта модель является предпочтительной). Существуют сотни тысяч разных драйверов устройств для Windows (работающих более чем с 1 млн различных устройств). Это огромное количество кода, который должен работать правильно. Будет гораздо лучше, если ошибка в процессе пользовательского режима приведет к недоступности устройства, чем к полному отказу системы. Ошибки в драйверах устройств режима ядра являются основной причиной этих ужасных синих экранов смерти (Blue Screen Of Death (BSOD)), возникающих, когда Windows обнаруживает фатальную ошибку в режиме ядра и завершает работу системы. BSOD — это практически то же самое, что и паника ядра (kernel panic) в системах UNIX.

По существу, компания Microsoft теперь официально признала то, что исследователи микроядер (таких, как MINIX 3 и L4) знали уже много лет назад: чем больше кода в ядре, тем больше в нем ошибок. Поскольку драйверы устройств составляют примерно 70 % кода ядра, то чем больше драйверов будет перенесено в процессы пользовательского режима (где ошибка может привести только к сбою самого драйвера, а не к краху всей системы), тем лучше.

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

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

Ввод-вывод будет рассмотрен далее, в разделе 11.7, а наиболее важная файловая система NT—NTFS — в разделе 11.8.

Диспетчер электропитания по возможности снижает энергопотребление, увеличивая время работы ноутбуков от батарей и сберегая энергию на настольных компьютерах и серверах. Настройка управления электропитанием может быть непростой, поскольку существует множество тонких различий между устройствами и шинами, которые подключают их к процессору и памяти. Энергопотребление зависит не только от того, какие устройства подключены к питанию, но и от тактовой частоты процессора, который также управляется диспетчером электропитания. Более подробно управление электропитанием будет рассмотрено в разделе 11.9.

Диспетчер процессов (process manager) управляет созданием и завершением процессов и потоков, включая настройку управляющих ими политик и параметров. Однако операционные аспекты потоков определяются уровнем ядра, который управляет планированием и синхронизацией потоков, а также их взаимодействием с управляющими объектами (такими, как АРС). Процессы содержат потоки, адресное пространство, а также таблицу описателей, содержащую те описатели, которые процесс может использовать для ссылки на объекты режима ядра.

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

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

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

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

Монитор безопасности (security reference monitor) обеспечивает работу сложных механизмов безопасности Windows, которые поддерживают международные стандарты по компьютерной безопасности, называемые Common Criteria (это развитие требований по безопасности Оранжевой книги Министерства обороны США). В этих стандартах содержится большое количество правил, которым должна соответствовать система (таких, как аутентифицированный вход в систему, аудит, заполнение нулями выделенной памяти и многое другое). Одно из правил требует, чтобы все проверки доступа реализовывались по всей системе единым модулем. В Windows этим модулем является монитор безопасности в ядре. Мы будем изучать систему безопасности более подробно в разделе 11.10.

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

Компонент LPC обеспечивает высокоэффективный межпроцессный обмен, используемый между работающими на одной системе процессами. Это один из транспортов данных, используемых стандартным средством вызова удаленных процедур (RPC) для реализации клиент-серверной модели вычислений. RPC использует в качестве транспорта также именованные каналы и TCP/IP.

LPC в Windows 8 был существенно улучшен (получив новое название ALPC Advanced LPC — расширенный LPC)), и теперь он обеспечивает поддержку новых функциональных возможностей RPC (в том числе RPC из компонентов режима ядра, таких как драйверы). LPC был критичным компонентом в первоначальной структуре NT, поскольку он используется уровнем подсистемы для реализации обмена между за- глушечными процедурами библиотек (которые работают во всех процессах) и процессом подсистемы, который реализует средства, являющиеся обычными для данного «персонажа» операционной системы (такого как Win32 или POSIX).

В Windows 8 реализована служба рассылок-подписок под названием WNF (Windows Notification Facility — средство уведомлений Windows). WNF-уведомления основаны на изменениях в экземпляре данных состояния WNF. Система рассылки (издатель) объявляет экземпляр данных состояния (объемом до 4 Кбайт) и сообщает операционной системе, как долго нужно поддерживать этот экземпляр (например, до следующей перезагрузки или постоянно). Издатель с помощью атомарной операции обновляет состояние соответствующим образом. Подписчик может быть нацелен на запуск кода, как только издатель изменит экземпляр состояния. Поскольку экземпляр состояния WNF содержит фиксированный объем заранее выделенных данных, никаких очередей данных, как в основанных на сообщениях IPC со всеми их сопутствующими проблемами в управлении ресурсами, здесь нет. Подписчикам гарантируется лишь то, что они могут увидеть самую последнюю версию экземпляра состояния.

Этот основанный на состоянии подход дает WNF принципиальное преимущество над механизмами IPC: издатели и подписчики разобщены и могут запускаться и останавливаться независимо друг от друга. Издателям не нужно выполняться во время начальной загрузки только для того, чтобы инициализировать их экземпляры состояний, поскольку те могут сохраняться операционной системой между перезапусками. Подписчики при запуске, как правило, не должны беспокоиться о прошлых значениях экземпляров состояний, поскольку все, что они должны знать об истории состояний, инкапсулировано в текущем состоянии. В сценариях, где значения прошлых состояний не могут по каким-то разумным причинам быть инкапсулированы, текущее состояние может предоставить метаданные для управления историческим состоянием, скажем, в файле или в постоянном объекте раздела, используемом в качестве кольцевого буфера. WNF является частью исходных NT API-интерфейсов и не выставляется (пока) через интерфейсы Win32. Но это средство широко используется внутри системы для реализации API-интерфейсов Win32 и WinRT.

В Windows NT 4.0 большая часть связанного с графическим интерфейсом Win32 кода была перенесена в ядро, поскольку оборудование в то время не могло дать требуемой производительности. Этот код ранее находился в процессе подсистемы csrss.exe, который реализует интерфейсы Win32. В ядре код графического интерфейса пользователя находится в специальном драйвере ядра (win32k.sys). Это изменение должно было повысить производительность Win32, поскольку при этом исключались дополнительные переходы из пользовательского режима в режим ядра и стоимость переключения адресных пространств (для реализации обмена через LPC). Но получилось это не так хорошо, как ожидалось, поскольку требования для выполняющегося в ядре кода очень высоки, а дополнительные издержки работы в режиме ядра перевешивают преимущества снижения стоимости переключений.

<< | >>
Источник: Э. ТАНЕНБАУМ Х. БОС. СОВРЕМЕННЫЕ ОПЕРАЦИОННЫЕ СИСТЕМ Ы 4-е ИЗДАНИЕ. 2015

Еще по теме Исполнительный уровень:

  1. ЦЕЛЬ ВОСПИТАНИЯ - ИЗУЧИТЬ РЕБЕНКА, УЗНАТЬ, КАКИЕ ПРОГРАММЫ У НЕГО ЕСТЬ НА ПРОЕКТНОМ УРОВНЕ, И БОЛЬШИНСТВО ИЗ НИХ ПЕРЕВЕСТИ НА ИСПОЛНИТЕЛЬНЫЙ УРОВЕНЬ.
  2. УРОВЕНЬ БОЛЕЗНЕЙ ЧЕЛОВЕКА - ЭТО УРОВЕНЬ ЕГО ОТКЛОНЕНИЯ ОТ СВОЕГО РУСЛА. ЗДОРОВЬЕ ЧЕЛОВЕКА - ЭТО ПОКАЗАТЕЛЬ НАХОЖДЕНИЯ ЧЕЛОВЕКА В СВОЕМ РУСЛЕ
  3. Статья 99. Исполнительный орган общества
  4. Статья 161. Исполнительный орган акционерного общества
  5. Исполнительная власть
  6. § 3. Стороны в исполнительном производстве
  7. 17.2. Государственное управление и исполнительная власть
  8. Парламент и исполнительная власть
  9. § 2. Органы исполнительной власти
  10. ПРОЕКТНЫЙ И ИСПОЛНИТЕЛЬНЫЙ УРОВНИ ПРОГРАММ
  11. Ментальный исполнительный центр (чакра 6Б),
  12. Система органов исполнительной власти
  13. ДЕЙСТВИЕ ИСПОЛНИТЕЛЬНОЕ
  14. § 2. Органы исполнительной власти