Архитектура современных ос
Чем отличаются потоки пользовательского режима от потоков ядра?
ОС Windows состоит из компонентов, работающих в режиме ядра, и компонентов, работающих в режиме пользователя.
Потоки пользовательского режима планируются в пользовательском режиме чем-то в процессе, и сам процесс - единственное, что обрабатывается планировщиком ядра.
Это означает, что ваш процесс получает определенное количество ресурсов от ЦП, и вы должны разделить его между всеми потоками пользовательского режима.
Простой случай, у вас есть два процесса, один с одним потоком и один с сотней потоков.
С упрощенной политикой планирования ядра поток в однопоточном процессе получает 50% ЦП, а каждый поток в процессе с сотнями получает по 0,5% каждый.
С потоками режима ядра, само ядро управляет вашими потоками и планирует их независимо. Используя один и тот же упрощенный планировщик, каждый поток получит лишь прикосновение менее 1% нагрузки ЦП (101 поток разделяет 100% ЦП).
С точки зрения того, почему переключение режима ядра стоит дороже, это, вероятно, связано с тем, что для этого вам нужно переключиться в режим ядра. Потоки пользовательского режима выполняют всю свою работу в пользовательском режиме (очевидно), поэтому нет необходимости вовлекать ядро в операцию переключения потоков.
Executive system - исполнительная часть NT
Исполнительная система - это совокупность компонентов, выолняющихся в привилегированном режиме - режиме ядра, и формирующих законченную ОС за исключением пользовательского интерфейса. В данном случае к компонентам исполнительной системы относятся также само ядро и слой абстрагирования от оборудования (HAL). В других источниках ядро и HAL рассматриваются как отдельные модули.
Диспетчер Plag and Play
Диспетчер PnP — основной компонент, от которого зависит способность Windows к распознаванию изменений в аппаратной конфигурации. Благодаря этому от пользователя не требуется знания тонкостей настройки устройств и системы при их установке и удалении. Так, диспетчер PnP позволяет портативному компьютеру с Windows при подключении к стыковочной станции автоматически обнаруживать дополнительные устройства стыковочной станции и делать их доступными пользователю. Поддержка Plug and Play требует взаимодействия на уровнях оборудования, драйверов устройств и операционной системы. Эта поддержка в Windows базируется на промышленных стандартах перечисления и идентификации подключенных к шинам устройств. Например, стандарт USB определяет способ самоидентификации устройств, подключенных к шине USB. Ha этой основе в Windows реализуются следующие возможности Plug and Play.
Диспетчер PnP автоматически распознает установленные устройства, и этот процесс включает перечисление устройств при загрузке и обнаружение их добавления или удаления во время работы системы.
Диспетчер PnP выделяет аппаратные ресурсы, собирая информацию о требованиях устройств к аппаратным ресурсам (прерывания, диапазоны адресов ввода-вывода, регистры ввода-вывода или ресурсы, специфичные для шин). B ходе арбитража ресурсов (resource arbitration) диспетчер PnP распределяет ресурсы между устройствами с учетом их требований. Поскольку устройства могут быть добавлены в систему после распределения ресурсов на этапе загрузки, диспетчер PnP должен уметь перераспределять ресурсы.
Другая функция диспетчера PnP — загрузка соответствующих драйверов. Ha основе идентификационных данных устройства он определяет, установлен ли в системе драйвер, способный управлять этим устройством. Если да, диспетчер PnP указывает диспетчеру ввода-вывода загрузить его. Если подходящий драйвер не установлен, диспетчер PnP режима ядра взаимодействует с диспетчером PnP пользовательского режима, чтобы установить устройство. При этом он может попросить пользователя указать местонахождение нужных драйверов.
Диспетчер PnP также реализует механизмы, позволяющие приложениям и драйверам обнаруживать изменения в аппаратной конфигурации. Иногда для работы драйверов и приложений требуется определенное устройство, поэтому в Windows имеются средства, которые дают возможность таким драйверам и приложениям запрашивать уведомления о наличии, добавлении и удалении устройств.
Диспетчер объектов.
Диспетчер Объектов (object manager), который является вероятно наименее известной из подсистем Исполнительной Системы NT, является также одним из наиболее важных. Главная роль операционной системы - это управление физическими и логическими ресурсами компьютера. Другие подсистемы Исполнительной Системы используют Диспетчер Объектов, чтобы определять и управлять объектами, которые представляют ресурсы.
Диспетчером объектов нельзя манипулировать из пользовательского режима напрямую, а его пространство имен является невидимым.
Диспетчер Объектов исполняет обязанности:
Поддержание единого пространства имен для всех именованных объектов системы.
Отвечает за создание, удаление и управление именованными и неименованными объектами ОС, представляющими системные ресурсы.
Обязанности по управлению объектами включают в себя идентификацию и подсчет ссылок. Когда прикладная программа открывает ресурс, Диспетчер Объектов или определяет местонахождение связанного с ресурсом объекта, или создает новый объект. Вместо возвращения прикладной программе, которая открыла ресурс, указателя на объект, Диспетчер Объектов возвращает непрозрачный (не имеющий смысла) идентификатор, называемый дескриптором. Значение дескриптора уникально в рамках прикладной программы, которая открыла ресурс, но не уникально между различными прикладными программами.
Система LPC(Local Process Communication)
Local Inter-Process Communication ( LPC , часто называемый также локальный вызов процедуры или Lightweight Procedure Call ) является внутренним, не имеющих документов межпроцессного взаимодействия объекта обеспечивается Microsoft Windows NT ядро для легкого IPC между процессами на том же компьютере.
Интерфейс LPC является частью недокументированных Windows NT в Native API , и как таковой не доступен для приложений , предназначенных для непосредственного использования. Тем не менее, она может быть использована косвенно в следующих случаях:
при использовании Microsoft RPC API для связи на местном уровне, то есть между процессами на одной машине
с помощью вызова API операционной системы Windows, которые реализуются с (А) LPC (см ниже)
Процедуры распределения памяти
Необходимым условием для того, чтобы программа могла выполняться, является ее нахождение в оперативной памяти. Только в этом случае процессор может извлекать команды из памяти и интерпретировать их, выполняя заданные действия.
Все алгоритмы распределения памяти разделены на два класса: алгоритмы, в которых используется перемещение сегментов процессов между оперативной памятью и диском, и алгоритмы, в которых внешняя память не привлекается
Рис 3 –– Методы распределения памяти
Подсистемы окружения(Environment Subsystems)
Подсистемы окружения (environment subsystems) – компоненты, предоставляющие доступ приложениям к некоторому подмножеству системных функций. Windows поддерживает две подсистемы окружения:
собственно Windows – при помощи данной подсистемы выполняются 32 разрядные приложения Windows (Win32), а также 16 разрядные приложения Windows (Win16), приложения MS DOS и консольные приложения (Console). За подсистему Windows отвечает системный процесс Csrss.exe и драйвер режима ядра Win32k.sys;
POSIX (Portable Operating System Interface for UNIX – переносимый интерфейс операционных систем UNIX) – подсистема для UNIX-приложений. Начиная с Windows Server 2003 R2 компонент, реализующий эту подсистему, называется SUA (Subsystem for UNIX-based Applications). Компонент не устанавливается в Windows по умолчанию.
Процессы сервисов (Service Processes)
Помимо обычных процессов, в операционной системе Microsoft Windows NT создаются так называемые сервисные процессы или сервисы (services). Эти процессы могут стартовать автоматически при загрузке операционной системы, по запросу приложений или других сервисов, а также в ручном режиме.
Функции, выполняемые сервисами, могут быть самыми разнообразными: от обслуживания аппаратуры и программных интерфейсов до серверов приложений, таких, например, как серверы баз данных или серверы World Wide Web (WWW).
Информация о всех серверах, установленных в системе, хранится в регистрационной базе данных: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servicies
Подсистема DLL(NTDLL.DLL)
Ntdll.dll является специальной библиотекой системной поддержки, предназначенной, главным образом, для использования DLL-библиотек подсистем. В ней содержатся функции двух типов:
функции-заглушки, обеспечивающие переходы от диспетчера системных служб к системным службам исполняющей системы Windows;
вспомогательные внутренние функции, используемые подсистемами, DLL-библиотеками подсистем и другими исходными образами.
Разделяемые системные библиотеки (system libraries)
Разделяемые библиотеки (shared libraries) - это такие библиотеки, которые загружаются приложениями при запуске. Если такая библиотека установлена правильно, то все приложения, запускаемые после установки библиотеки, начинают использовать эту новую разделяемую библиотеку. На самом деле, всё гораздо гибче и соверщеннее, ибо линуксовая их реализация позволяет:
совершенствовать библиотеки, продолжая поддерживать программы, использующие более старые версии этих библиотек, не совместимые с новыми.
заменять какие-то конкретные библиотеки или даже конкретные функции в библиотеке во время выполнения какой-то конкретной программы.
проделывать всё это "на горячую", когда программа запущена и какие-то библиотеки уже использует.