Диспетчер процессов — компонент, который отслеживает два типа объектов; объекты процесса и объекты нитей правления. Процесс определяется как адресное пространство, набор доступных процессу объектов и совокупность выполняемых в контексте процесса нитей управления. Нить управления (thread) является основным управляемым элементом в системе. Она имеет собственный набор регистров, собственный стек ядра, блок среды нити и стек пользователя в адресном пространстве процесса.
Диспетчер процессов —компонент Windows NT, который управляй созданием и завершением процессов. Он обеспечивает набор стандартных услуг по созданию и использованию нитей управления и процессов в контексте специфической среды подсистемы. Кроме того, диспетчер процессов в некоторой степени диктует правка для нитей и процессов. Дополнительно, Windows NT позволяет подсистемам среды определять для них специфические правота.
Диспетчер процессов не налагает каких-либо требований по иерархии или группировке для процессов, а также не определяет отношений порожденности. Модель процессов Windows NT работает совместно с моделью безопасности и диспетчером виртуальной памяти для обеспечения безопасности процессов. Каждому процессу назначается маркер безопасного доступа (security access token), называемый первичным маркером процесса. Этот маркер используется процедурами проверки правильности доступа Windows NT, когда нити управления процесса ссылаются па защищенные объекты. Диспетчер виртуальной памяти
Архитектура памяти для Windows NT основана на использовании подкачиваемой по запросу виртуальной памяти системы и плоском, линейном адресном пространстве с 32-разрядным доступом.
Виртуальная память (virtual memory) позволяет операционной системе управлять большим объемом памяти, чем тот объем, который компьютер физически содержит. Каждый процесс размещается в уникальном виртуальном адресном пространстве, которое представляет собой набор адресов, доступных для использования нитями управления процесса. Это виртуальное адресное пространство разделяется на равные блоки, или страницы (pages).
Каждый процесс может использовать до 4 Гб собственного виртуального адресного пространства; из mix 2 Гб зарезервированы для нужд программы, а оставшиеся 2 Гб - для системы. Windows NT может использован до 4 Гб физической памяти, если аппаратные средства компьютера могут обеспечить подобный объем. Лишь некоторые операционные системы позволяют работать с памятью таких размеров. Например, MS OS/2 версии 1. 3 может адресовать . тишь 16 Мб физической памяти. Подачка по запросу (demand paging) используя метод, посредством которого данные странично переносятся из физической памяти во временный страничный файл на диске. В случае необходимости использования этих данных для функционирования определенных процессов страничные данные переписываются обратно в физическую память.
Диспетчер виртуальной памяти отображает виртуальные адреса в адресном пространстве процесса на физические страницы в памяти компьютера. При этом от нитей управления процесса скрывается физическая организация памяти. Это гарантирует, что нить управления может обращаться, в случае необходимости, к памяти своего процесса, не затрагивая память других процессов. Следовательно просмотр виртуальной памяти процесса нитью управления намного упрощен по сравнению с реальным расположением страниц в физической памяти. Вследствие того что каждый процесс имеет раздельное адресное пространство, нити управления одного процесса не могут просматривать или изменять память другого процесса без соответствующего разрешения. Средства вызова локальных процедур
Приложения н подсистемы среды реализуют взаимоотношения типа “клиент-сервер”. Это означает, что клиент (приложение) обращается к серверу среды (подсистеме) для удовлетворения запроса о предоставлении некоторого типа сервиса системы. Для реализации взаимодействия “клиент-сервер” между приложениями и подсистемами среды Windows NT обеспечивает механизм связи между ними. Исполняющая система предоставляет средства прохождения сообщении, которые называются средствами вызова локальных процедур (LPC — Local Procedure Call). Они функционируют подобно вызовам удаленных процедур (RPC), используемому для работы в сетевой среде (описаны в Networking Guide, Chapter I, “Windows NT Networking Architecture”). Однако средства LPC оптимизированы для процессов, выполняющихся на одном компьютере. Прикладные программы взаимодействуют с подсистемами среды, передавая сообщения через средства LPC. Процесс прохождения сообщения скрыт от клиентского приложения функциональными заглушками (slubs); заглушки представляют собой невыполняемые фрагменты, которые используются при обращении к серверам среды. Заглушки реализованы в форме специальных динамически связываемых библиотек (DLL).
Когда приложение производит обращение к интерфейсу прикладных программ (API —application program interface) подсистемы среда, заглушка клиентского процесса (приложения) упаковывает параметры для вызова и направляет их серверному процессу (подсистеме), который осуществляет выполнение. Средства LPC предусматривают, что после передачи данных серверу производится ожидание ответа.
Рассмотрим, например, как этот процесс работает в подсистеме Win32. Когда приложение Win32 загружено дня выполнения, оно связывается с DLL, которая содержит заглушки для всех функций Win32 API. В случае, если приложение осуществляет вызовы функции Win32 (в нашем примере, Win32-функции CreateWindow), обращение обрабатывается следующим образом.
1. Клиентское приложение Win32 вызывает заглушку функции CreateWindow() из DLL. 2. Заглушка формирует сообщение, которое содержит все данные, необходимые для создания окна, и посылает это сообщение процессу сервера Win32 (подсистеме Win32).
3. Подсистема Win32 получает сообщение и вызывает реальную функцию CreateWindow(). В результате этого создается окно.
4. Подсистема Win32 посылает сообщение, содержащее результаты выполнения функции CreateWindow(), обратно заглушке в DLL,
5. Заглушка распаковывает сообщение сервера подсистемы и возвращает результаты клиентскому приложению Win32.
Приложение воспринимает, что окно было создано функцией CreateWindow() из DLL. От приложения скрыто, что работа фактически выполнялась процессом сервера Win32 (подсистемой Win32), что для активизации этого процесса посылалось сообщение, и даже что существует процесс сервера Win32. Кроме тою, приложение не знает, что подсистема обращалась к одному или нескольким серверам исполняющей системы для поддержки ее обращения к CreateWindow(). Диспетчер ввода-вывода
Диспетчер ввода-вывода является частью исполняющей системы Windows NT, которая управляет всем вводом и выводом для операционной системы. Основное назначение диспетчера ввода-вывода—управление связью между драйверами. Диспетчер ввода-вывода поддерживает все драйверы файловой системы, драйверы аппаратных средств, сетевые драйверы и обеспечивает для них гетерогенную среду. Он предоставляет формальный интерфейс, доступный для вызовов всеми драйверами. Этот однородный интерфейс позволяет диспетчеру ввода-вывода одинаково взаимодействовать со всеми драйверами, без какой-либо информации о фактическом управлении работой устройства. Диспетчер ввода-вывода также содержит процедуры поддержки драйверов, специально разработанные для драйверов файловой системы, драйверов аппаратных средств и сетевых драйверов.
Модель ввода-вывода Windows NT использует многоуровневую архитектуру, которая позволяет отдельным драйверам отвечать за логически законченный уровень обработки ввода-вывода. Например, драйверы самого низкого уровня управляют физическими устройствами компьютера (называются драйверами устройств—device drivers). Другие драйверы являются надстройкой к драйверам устройств. Драйверам более высокого уровня неизвестны любые подробности работа физических устройств. С помощью диспетчера ввода-вывода драйверы более высокого уровня просто передают запросы логического ввода-вывода драйверам устройств, которые и обращаются к обслуживаемым ими физическим устройствам. Устанавливаемые файловые системы Windows NT и сетевые редиректоры (redirectors)— примеры работающих таким образом драйверов высокого уровня. Использование подобной схемы обеспечивает легкую замену драйверов файловой системы и драйверов устройств. Кроме того, это позволяет быть активными одновременно нескольким файловым системам и устройствам, так как они адресуются через формальный интерфейс.
Драйверы взаимодействуют друг с другом, используя структуры данных, называемые пакетами запроса ввода-вывода (I/O request packets). Драйверы передают пакеты запроса ввода-вывода друг другу через диспетчер ввода-вывода, который доставляет пакеты соответствующим целевым драйверам. Самый простой способ выполнения операций ввода-вывода состоит в том, чтобы синхронизировать выполнение приложений с завершением запрашиваемых ими операций ввода-вывода (такой подход известен под названием синхронного ввода-вывода—synchronous I/O). Когда подобное приложение выполняет операцию ввода-вывода, функционирование собственно приложения блокировано. После завершения операции ввода-вывода приложению разрешается продолжение дальнейшего выполнения. Одним из способов оптимизации эффективности приложении является применение асинхронного ввода-вывода (asynchronous I/O); этот метод используется многими процессами в Windows NT. Когда приложение инициализирует операцию ввода-вывода, диспетчер ввода-вывода принимает запрос, но не блокирует работу приложения в процессе выполнения ввода-вывода. Вместо этого приложение продолжает свое функционирование. Большинство устройств ввода-вывода очень медленно в сравнении с процессором компьютера; таким образом, прикладная программа может выполнить множество операции в процессе ожидания завершения операции ввода-вывода. Когда подсистема среды выдает асинхронный запрос ввода-вывода, диспетчер ввода-вывода возвращается к подсистеме среды немедленно после помещения запроса в очередь, без ожидания завершения операции драйвером устройства. В это время отдельная нить управления диспетчера ввода-вывода выполняет запросы из очереди наиболее эффективным образом (не обязательно в порядке поступления)
По завершении любого запроса ввода-вывода диспетчер ввода-вывода уведомляет об этом процесс, запросивший операцию.
Так как применение асинхронного ввода-вывода разрешает приложению использовать процессор компьютера во время операций ввода-вывода, это затрудняет для приложения определение завершения операции ввода-вывода. Некоторые приложения применяют функцию повторного вызова (АРС), которая вызывается после завершения асинхронной операции ввода-вывода. Другие приложения используют объекты синхронизации, типа событий или описателей фактов, которые система ввода-вывода приводит в соответствующее состояние после выполнения ввода— вывода. Диспетчер кэша
Архитектура ввода-вывода содержит единственный диспетчер кэша (Cache Manager), который осуществляет кэширование ддя всей системы ввода-вывода. Кэширование (caching)—метод, используемый файловой системой для увеличения эффективности. Вместо непосредственной записи и считывания с диска, часто используемые файлы временно сохраняются в кэш-памяти; таким образом, работа с этими файлами выполняется в памяти. Операции с данными, находящимися в памяти, производятся значительно быстрее операции с данными на диске.
Диспетчер кэша использует модель отображения файла, которая интегрирована с диспетчером виртуальной памяти Windows NT. Диспетчер кэша обеспечивает службу кэширования для всех файловых систем и сетевых компонентов, функционирующих под управлением диспетчера ввода-вывода. В зависимости от объема доступной оперативной памяти диспетчер кэша может динамически увеличивать или уменьшать размер кэша. Когда процесс открывает файл, который уже находятся в кэше, диспетчер кэша просто копирует данные из кэша в виртуальное адресное пространство,
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18
