I. Механика

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

Помимо управления ресурсами и поддержки их совместного использова­ния, объектная система NT служит центром, в котором обеспечивается защита ресурсов. При открытии процессом описателя объекта активизируется подсис­тема защиты NT. С каждым объектом связана маленькая база данных, называемая списком контроля доступа (access control list, ACL) и содержащая информацию о том, какие процессы имеют доступ к объекту и какие действия эти процессы могут над ним производить. При открытии описателя объекта процесс указыва­ет, какие действия он собирается производить с объектом. Например, процесс может открыть файл для доступа по чтению. Система защиты проверяет,

Рис. 2-12. Создание объектов NT.

 

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

 

9. Базовые сервисы: виртуальная память, I\O и файловые системы.

 

Разные ОС по-разному представляют физическую память и требуют от своих программ доступа к ней по определенным правилам. В Windows NT приклад­ные программы исполняются в одной из сред, которые ведут себя как некото­рая ОС: Windows, MS-DOS, POSIX или OS/2. Задача состоит в том, чтобы при­ложения всех типов могли выполняться без изменений и без столкновений друг с другом в памяти.

Каждая подсистема среды Windows NT представляет память в том виде, ко­торый ожидают от нее приложения. Исполнительная система NT, лежащая ниже подсистем среды, имеет свою собственную структуру памяти, к которой подси­стемы обращаются, вызывая базовые сервисы NT.

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

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

В Windows NT ОС располагается в верхней части виртуальной памяти, а пользовательский код и данные — в нижней, как показано на рис. 2-13. Поток пользовательского режима не может производить непосредственную запись и чтение системной памяти.

Часть системной памяти, называемая резидентным пулом (nonpaged pool), никогда не откачивается на диск и используется для хранения некоторых объек­тов NT и других важных структур данных. Другая часть системной памяти, которая может быть перемещена на диск, называется нерезидентным пулом (paged pool). Всю пользовательскую память можно откачать.

Ввод-вывод и файловые системы

Как и в случае с памятью, подсистемы среды обеспечивают такие средства ввода-вывода, которых ожидают от них приложения. Эти специфичные средства обеспе­чивают подсистемы среды при помощи обращений к базовым сервисам NT.

В основе системы ввода-вывода лежит асинхронная модель ввода-вывода, однако подсистемам среды предоставляются системные сервисы, позволяющие им реализовывать как асинхронную, так и синхронную модели. Асинхронный ввод-вывод (asynchronous I/O) позволяет программе запросить выполнение операции ввода-вывода, после чего продолжать выполнение другой работы, пока устройство не закончит пересылку данных. Система ввода-вывода автома­тически уведомляет программу о завершении ввода-вывода, так что программа может выполнять последующую обработку. Так как устройства ввода-вывода обычно работают существенно медленнее процессоров, то программа, выпол­няющая много операций ввода-вывода, в ряде случаев может повысить свою производительность, используя асинхронный ввод-вывод.

Рис. 2-13. Адресное пространство NT.

 

Windows NT поддерживает несколько файловых систем, включая файло­вую систему FAT (file allocation table), высокопроизводительную файловую сис­тему (high performance file system, HPFS) и новую файловую систему, под назва­нием файловая система NT (NT file system, NTFS). NTFS расширяет возможности как FAT, так и HPFS, добавляя к ним следующие:

• Средство восстановления файловой системы, позволяющее быстро вос­станавливать данные на диске после системного сбоя.

• Способность с легкостью работать с носителями данных большого объема — до 2⁶⁴ байт, или приблизительно 17 миллиардов гигабайт.

• Средства контроля доступа, в том числе файлы "только для исполнения".

• Имена файлов, записанные в стандарте Unicode, что позволяет переме­щать документы между компьютерами, находящимися в разных стра­нах, без искажения имен файлов и каталогов.

• Поддержка среды ОС POSIX, включая жесткие связи (hard links), имена, отличающиеся только регистром букв, и информацию о времени пос­леднего открытия файла.

• Средства для будущего расширения, такие как обработка транзакций для поддержки отказоустойчивых приложений, задаваемые пользовате­лем номера версий файла, несколько потоков данных в одном файле, гибкие возможности задавать имена и атрибуты файлов, а также под­держка популярных файл-серверов.

Диспетчер ввода-вывода позволяет драйверам устройств и файловым си­стемам (которые он также рассматривает как драйверы "устройств") динамичес­ки загружаться и выгружаться из системы, в зависимости от потребностей пользователя. Драйверы являются модульными и могут располагаться слоями один над другим, что позволяет, например, разным файловым системам использовать для доступа к файлам один и тот же драйвер диска, как показано на рис. 2-14.

Рис. 2-14. Слои драйверов.

 

Послойная модель драйверов позволяет также вставлять в иерархию но­вые драйверы. Например, логические драйверы файловых систем или драйверы отказоустойчивости могут располагаться на средних уровнях иерархии.

Windows NT обеспечивает доступ к файлам в сетях LAN Manager при помо­щи драйвера файловой системы, называемого редиректором Windows NТ. Редиректор принимает запросы для удаленных файлов и направляет их серверу LAN Manager на другой машине.

 

10. Интернационализация, регионы, Unicode.

 

Интернационализация

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

Видимая для пользователя часть поддержки интернационализации нахо­дится в Панели Управления (Control Panel) Windows NT, как показано на рис. 2-15.

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

Рис. 2-15. Диалоговое окно установок интернационализации.

В Windows NT 4.0 национальная поддержка получила дальнейшее развитие. В Control Panel можно указать такие параметры, как регион системы, устанавливаемый по умолчанию, регион текущего пользователя, зарегистрировавшегося локально, а также раскладки клавиатуры.

 

Регионы

Рынки с различными национальными и культурными особенностями, называе­мые регионами (locales), предъявляют к программному обеспечению разные требования. Основное требование — возможность для пользователя работать с программами на своем родном языке, используя привычные соглашения о типе представления данных.

Регион — это совокупность таких параметров, как язык, страна и кодовый набор, т. е. двоичные коды, используемые для представления символов данного языка. (Одним из таких кодовых наборов является Windows ANSI.) При установ­ке Windows NT пользователь задает язык, и с ним связывается регион по умолча­нию. Регион по умолчанию предоставляет пользователю соответствующие мест­ной культуре начальные установки для раскладки клавиатуры, порядка сортировки, вида валюты и форматов записи времени и даты. Любую из этих устано­вок по умолчанию пользователь может переопределить.

Тем не менее, желательна еще большая гибкость. В многоязычных странах, таких как Канада, Швейцария и Бельгия, пользователям необходимо регулярно переключаться между двумя или несколькими языками. Более того, некоторые компании, в том числе и Microsoft, имеют подразделения, в которых пользуются несколькими рабочими языками. В идеале каждый пользователь должен иметь возможность в любое время переключаться или пересылать данные между реги­онами без потери информации. Чтобы обеспечить эту возможность, приложе­ния (в данном случае Windows) необходимо разделить на две части:

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

• Данные, которые для каждого региона должны преобразовываться.

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

Для поддержки локализации подсистема Win32 содержит API поддержки национальных языков (national language support, NLS), которые предоставляют приложениям (и Windows NT) корректные с точки зрения национальной куль­туры: сравнение строк; таблицы сортировки символов разных языков; процеду­ры форматирования даты, времени и денежных сумм; процедуры для определе­ния текущего региона и других регионов, представленных в системе. Кроме того, NLS API содержат функции преобразования международного кодового набора, используемого Windows NT, в другие распространенные кодовые набо­ры. И подси­стема Win32, и библиотека времени выполнения С содержат свои собственные API, использующие NLS. Все эти средства позволяют приложениям поддержи­вать локализацию, не дублируя требуемый для этого значительный объем ин­формации (таблицы, кодовые наборы и т.д.).

Unicode

Самый низкий уровень поддержки локализации — это представление отдельных символов, кодовые наборы. В США для представления информации традицион­но используется стандарт ASCII (American Standard Code for Information Interchange — Американский стандартный код для обмена информацией). Одна­ко, для европейских и других стран этот код не является адекватным, так как в нем нет многих символов и знаков. Например, там нет знака британского фунта, а также диакритических символов, используемых во французском, немецком, датском и испанском языках.

Международная организация по стандартизации ISO (International Standards Organization) установила стандартный кодовый набор, называемый Latin 1 (стан­дарт ISO 8859-1) и определяющий коды для всех европейских символов, кото­рых нет в ASCII. В Microsoft Windows используется несколько измененный вари­ант Latin 1, который называется кодовым набором Windows ANSI. Windows ANSI является однобайтовой схемой кодирования (single-byte coding scheme), так как для представления каждого символа в нем используется 8 бит. Максималь­ное число символов, которое можно представить с использованием 8 бит, равно 256 (2⁸).

Алфавит (script) — это набор литер, необходимых для записи текста на некотором языке. Часто один и тот же алфавит используется несколькими языками: например, кириллица применяется как в русском, так и в украинском. Windows ANSI и другие однобайтовые схемы могут закодировать количество символов, достаточное для представления букв любого западного алфавита. Однако восточные алфавиты, такие как японский или китайский, в которых используются тысячи разных символов, не удается закодировать при помощи однобайтовой схемы. В таких случаях используют двухбайтовую схему кодиро­вания, когда для каждого символа требуется 16 бит, либо многобайтовую, в кото­рой одни символы представляются 8 битами, а другие 1б, 24 или 32 битами. Пос­ледняя схема требует применения сложных алгоритмов разбора для определе­ния длины данного символа. Более того, большое число кодовых наборов озна­чает, что данному коду могут соответствовать совершенно разные символы на разных компьютерах, в зависимости от используемых на этих компьютерах кодо­вых наборов.

Для решения проблем множественности схем кодирования и для поддер­жки более широкого набора алфавитов Windows NT использует для представле­ния данных новый стандарт Unicode. Unicode - это 16-разрядная схема кодиро­вания символов, в которой можно представить 65536 (2¹⁶) символов. Этого дос­таточно для всех современных, а также нескольких старых или мертвых языков, имеющих ограниченное применение (например, санскрита и, может быть, еги­петских иероглифов). Unicode также включает знаки препинания, математичес­кие символы и набор графических символов, называемых дингбатами (dingbats), после чего еще остается много места для расширений.

В Unicode "суть" символа отделена от информации о шрифте или форма­тировании, используемой для его отображения. Каждому коду соответствует один (и только один) символ; для отображения символов Unicode в различных стилях и формах к ним применяется информация о шрифте. Раскладка алфави­тов и символов в Unicode показана на рис. 2-16.

Рис. 2-16. Раскладка Unicode.

Хотя подсистема Win32 предоставляет варианты функций API как для строк ANSI, так и для строк Unicode, последний является "родным" кодовым на­бором Windows NT. Все строки в системе, включая имена объектов, имена путей, имена файлов и каталогов, представляются 16-разрядными символами Unicode. Даже подсистема Win32 преобразует передаваемые ей символы ANSI в символы Unicode, прежде чем обрабатывать их; перед возвратом управления она, при необходимости, преобразует строки обратно из Unicode в ANSI.

Применение Unicode позволяет устранить все ограничения на набор сим­волов, которые могут быть представлены в Windows NT. Так как Unicode обеспе­чивает уникальный код для каждого символа любого алфавита, Windows NT может гарантировать, что преобразование символов как на выходе, так и на входе в систему будет всегда правильным.

 

11. Структурная обработка исключений.

 

Вторая особая архитектура, поддерживаемая и используемая Windows NT, назы­вается структурной обработкой исключений. Исключения (exceptions) — это синхронные ошибки или нетипичные события, вызывающие исполнение кода вне обычного потока управления. В отличие от прерываний, которые генериру­ются внешним источником, исключения возникают при исполнении програм­мой некоторого кода и могут быть воспроизведены.

Например, когда программа вызывает функцию С mallocQ, типичным ре­зультатом будет выделение памяти и возвращение указателя на нее. Исключи­тельная ситуация возникает тогда, когда из-за некоторой проблемы, например, недостатка свободной памяти, не удается выделить новый блок. При этом функ­ция возвращает указатель NULL

Возврат особого значения, указывающего на исключение — это обычная, но примитивная форма обработки исключений, и она имеет ряд недостатков. Во-первых, программист обязан скрупулезно соблюдать ритуал проверки воз­вращаемого значения и либо реагировать на ошибки, либо передавать их на более высокий уровень программы. Если на одном из уровней проверка не про­водится, то ошибки могут повлиять на не имеющие отношения к месту их воз­никновения части программы. Во-вторых, текст программы загромождается операторами If...Then...Else, обрабатывающими нетипичные случаи. В-третьих, информация о причине возникновения проблем не всегда легко доступна коду, который должен обработать ошибку.

Исключения могут обнаруживаться как программно, так и аппаратно. На­пример, аппаратура обнаруживает исключения "деление на 0", тогда как про­граммное обеспечение определяет нарушения защиты памяти. Структурная об­работка исключений — это метод, применяемый Windows NT для обработки как программных, так и аппаратных исключений, с использованием структур управ­ления (отсюда и название) некоторого языка программирования. Структурная обработка исключений позволяет любому блоку кода определить, от исключе­ний каких типов он хочет защищаться, и зарегистрировать специальный учас­ток кода — обработчик исключений (exception manager), который исполняется при возникновении исключений заданных типов в этом блоке.

Приводимый ниже код представляет собой пример процедуры на Microsoft С, в которую входит обработчик исключений. Функция является моди­фицированным вариантом стандартной библиотечной функции strlen(), воз­вращающей длину строки, которая заканчивается нулевым символом.

Обычная функция strlen() быстро просматривает память по одному симво­лу, до тех пор пока не найдет символ NULL. Но если строка не заканчивается нулем или указатель на строку неверен, то strlen() может внезапно завершиться с исключением "нарушение защиты памяти".

Приведенная здесь модифицированная версия перехватывает исключение и возвращает осмысленное значение (не обязательно верное, просто осмыслен­ное) вместо аварийного завершения программы. Новое ключевое слово try слу­жит отметкой начала блока кода, который может вызвать нарушение защиты. Если исключение возникает внутри этого блока, то управление передается на ключевое слово except, за которым в скобках следует фильтр исключений. Фильтр исключений дает возможность задать обработку только для некоторых типов исключений. Если значение фильтра равно EXCEPTION_EXECUTE_HANDLER, то исполняется обработчик исключения, в данном случае оператор return (count). Фильтры исключений — это достаточно мощное средство, так как они могут обращаться к локальным данным и иметь любую сложность. Применение филь­тров позволяет исполнять обработчик только при точном соблюдении задан­ных условий. Передача управления обработчику исключений называется воз­буждением исключения (raising an exception). Обратите внимание, что код обработки ошибок удален с основного пути выполнения программы.

Каждый блок кода может иметь собственный обработчик исключений, и обработчики могут быть вложены друг в друга. При возникновении исключения фильтр исключений может проверить его тип и по результатам проверки ука­зать ОС: выполнить обработчик исключений, продолжить выполнение програм­мы, завершить работу программы или продолжить поиск обработчика в охваты­вающем блоке кода.

Исключения ОС — не единственный тип исключений, которые может об­рабатывать приложение. Приложения сами могут генерировать исключения при помощи функции Win32 API RaiseException(), вызывая тем самым передачу-управления соответствующему обработчику исключений. Для поддержки этой операции ОС регистрирует обработчики исключений и просматривает их в надлежащем порядке в случае возбуждения исключения. Если ни один из обра­ботчиков не взялся за обработку проблемы, то ОС завершает программу, вызвав­шую ошибку. Средство обработки исключений Windows NT не зависит от ис­пользуемого языка программирования; один и тот же механизм используется для всех языков. Каждый язык определяет, каким образом в нем раскрывается этот механизм.

Другой тип обработчика исключений, известный как обработчик завер­шения (termination handler), позволяет приложению гарантировать выполнение некоторого блока кода, даже если защищенный блок завершается ненормально. Обработчики завершения часто содержат код, освобождающий ресурсы, чтобы в случае ненормального завершения процедуры выделенные ею ресурсы были возвращены системе. Следующий фрагмент кода иллюстрирует назначение об­работчика завершения:

Критическая секция — это синхронизационный объект Win32, который гарантирует, что данный блок кода будет исполняться одновременно не более чем одним потоком. В нашем примере поток получает доступ к критической секции, выделяет буфер, после чего модифицирует его содержимое. Если слу­чится что-то не то (например, произойдет необработанное исключение) и про­цедура завершится в тот момент, когда поток находится в критической секции, то остальные потоки, ожидающие доступ к этому ресурсу, будут заблокированы навсегда. Более того, буфер, выделенный потоком, будет потерян, так как ОС не сможет его освободить сама. (Разработчики часто называют такого рода ошиб­ки утечками памяти. Если их происходит слишком много, то память постепенно "утекает".) Обработчик завершения гарантирует, что поток освободит объект-критическую секцию и буфер. Обработчики завершения исполняются всегда, когда поток управления выходит из тела блока try...finally, независимо от способа, которым происходит этот выход.

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

 

 

Объектная модель Windows NT:

12. Объекты. Использование объектов.

13. Файловая и объектная модель.

14. Структура и типы объектов.

15. Управление объектами: имена, каталоги.

16. Управление объектами: домены, символические связи.

 

Контроль доступа

к объектам WinNT:

17. Описатели и удержание объектов. Учет использования ресурсов..

 

Хотя имена объектов важны для хранения и совместного использования объек­тов, они используются не часто. Процесс указывает имя объекта, когда он созда­ет объект или открывает его описатель. После этого процесс использует описа­тель объекта. Ссылка на объект при помощи его описателя выполняется быст­рее, чем по имени, так как диспетчер объекта может опустить поиск имени и найти объект непосредственно.

Описатель объекта NT — это индекс в специфичной для процесса таблице объектов (object table). Таблица объектов процесса содержит указатели на все объекты, описатели которых открыты процессом. Процесс может получить описатель объекта, создав объект, или открыв описатель существующего объек­та, или унаследовав описатель от другого процесса, или получив дубликат опи­сателя из другого процесса. На рис. 3-7 показана связь между процессом и его таблицей объектов.

Каждый вход таблицы объектов содержит предоставленные права доступа для соответствующего описателя и его режим наследования (inheritance designa­tion) — иными словами, получат ли процессы, созданные данным процессом, копию этого описателя в своих таблицах объектов. Хотя термин описатель (handle), строго говоря, относится только к индексу в таблице, разработчики используют этот термин и для обозначения данных, хранящихся в соответству­ющем входе таблицы.

Рис. 3-7. Структура таблицы объектов.

Два процесса совместно используют объект, если оба они открыли его опи­сатели. Каждый из этих описателей уникален, как показано на рис. 3-8.

Создатель объекта определяет, могут ли описатели объекта наследо­ваться из процесса теми процессами, которые он создал. Это средство по­зволяет поддерживать среды, включая Win32 и POSIX, разрешающие насле­дование ресурсов.

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

Рис. 3-8. Совместное использование объекта.

 

объект-процесс, диспетчер объектов вызывает метод "удалить" для объектов-процессов, который закрывает все описатели в таблице объектов процесса.

Удержание объектов

Так как все процессы пользовательского режима, осуществляющие доступ к некоторому объекту, должны вначале открыть его описатель, то диспетчер объек­тов может легко отслеживать, сколько процессов, и даже какие именно, исполь­зуют данный объект. Отслеживание открытых описателей — это первый шаг в реализации удержания объектов (object retention), т.е. сохранения временных объектов только на то время, пока они используются, с последующим удалением.

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

Вторая фаза удержания объектов — это прекращение удержания (т.е. уда­ление объектов), когда они более не используются. Так как ОС обычно осуще­ствляет доступ к объектам посредством указателей, а не описателей, диспетчер объектов должен также учитывать количество указателей на объект, которое он передал процессам ОС. Всякий раз при выдаче нового указателя на объект диспетчер объектов увеличивает счетчик ссылок объекта (reference count);

Когда поток ОС заканчивает работу с объектом, он обращается к диспетчеру объектов для уменьшения счетчика ссылок. Таким образом, даже после того, как счетчик описателей достиг нуля, счетчик ссылок может оставаться положи­тельным, указывая, что ОС продолжает использовать объект. В конце концов счетчик ссылок обнуляется. Когда это происходит, диспетчер объектов удаляет объект из памяти.

Благодаря такой реализации удержания объектов приложение гарантиру­ет, что объект и его имя остаются в памяти, просто сохраняя открытым описа­тель этого объекта. Программистам, пишущим приложения, которые состоят из двух или более взаимодействующих между собой процессов, не нужно беспоко­иться о том, что один процесс может удалить объект, прежде чем другой закон­чит работу с ним. Кроме того, закрытие описателей объекта приложениями не приводит к удалению объекта, если его по-прежнему использует ОС. Например, один процесс может создать другой процесс для выполнения некоторой про­граммы в фоновом режиме; сразу же после этого первый процесс закрывает описатель второго. Так как второй процесс нужен ОС для выполнения про­граммы, то она сохраняет ссылку на объект-процесс. Только после того как фоновая программа закончит выполнение, диспетчер объектов уменьшит счет­чик ссылок второго процесса и затем удалит этот процесс.

Учет использования ресурсов

Учет использования ресурсов, так же как и удержание объектов, тесно связан с использованием описателей объектов. Если у объекта есть положительный счет­чик открытых описателей, это означает, что некоторый процесс использует данный ресурс. Это также означает, что некоторый процесс "платит" за память, занятую объектом. Когда счетчик описателей объекта обнуляется, процесс, пе­ред тем использовавший объект, не должен более за это платить.

Многие ОС используют квоты для ограничения доступа процессов к сис­темным ресурсам. Однако типы квот, налагаемых на процессы, иногда бывают слишком разнообразными и сложными, а код их учета разбросан по всей систе­ме. Например, пусть в некоторой ОС компонент ввода-вывода учитывает и огра­ничивает число файлов, которые может открыть процесс, в то время как компо­нент, отвечающий за распределение памяти, накладывает ограничения на объем памяти, который могут использовать потоки процесса. Компонент управления процессами ограничивает число процессов, которые может создать пользова­тель, или устанавливает максимальное число потоков в этих процессах. Каждое из этих ограничений отслеживается и выполняется различными компонентами ОС.

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

 

18. Методы объектов.

 

Диспетчер объектов использует их сходные черты, чтобы работать с объектами единообразно. Однако, у объектов есть и различия, иногда весьма существенные. Диспетчер объектов был бы слишком большим и сложным, если бы ему при­шлось учитывать все особенности различных типов объектов. Он также должен был бы изменяться при добавлении к системе нового типа объектов. Чтобы из­бежать этого, диспетчер объектов предоставляет возможности перехвата, кото­рые другие компоненты исполнительной системы NT могут использовать для выполнения задач, уникальных для их типов объектов. Эти средства перехвата называются методами объектов (object method).

Когда компонент исполнительной системы создает новый тип объекта, он может зарегистрировать в диспетчере объектов один или несколько мето­дов. После этого диспетчер объектов вызывает данные методы в строго определенные моменты жизни объекта этого типа: обычно, когда объект создается, удаляется или некоторым образом модифицируется. Методы, поддерживаемые диспетчером объектов, перечислены в табл. 3-5.

Таблица 3-5. Методы объектов

Метод

Когда вызывается

Открыть Закрыть Удалить Запросить имя Разбор Защита

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

Пример использования метода "закрыть" имеет место в системе ввода-вы­вода. Диспетчер ввода-вывода регистрирует метод закрытия для файлового типа объектов, а диспетчер объектов вызывает данный метод всякий раз, когда он зак­рывает описатель файлового объекта. Метод "закрыть" проверяет, установлены ли процессом, закрывающим файл, какие-либо блокировки этого файла, и если да, то удаляет их. Проверка на наличие блокировок файла не является действием, ко­торое может или должен осуществлять непосредственно диспетчер объектов.

Перед удалением из памяти временного объекта диспетчер объектов вы­зывает метод "удалить", если он был зарегистрирован. Диспетчер виртуальной памяти для объектов типа "секция", например, регистрирует данный метод, ко­торый освобождает физические страницы, занятые секцией. Метод также гаран­тирует, что все внутренние структуры данных, выделенные для секции диспетче­ром виртуальной памяти, будут удалены перед удалением объекта—секции. Эту работу тоже не может выполнить диспетчер объектов, так как он ничего не зна­ет о внутренних принципах работы диспетчера виртуальной памяти. Методы удаления для других типов объектов выполняют аналогичные функции.

Метод "разбор" (и аналогично, метод "получить имя") позволяет диспет­черу объектов переложить задачу поиска объекта на вторичный диспетчер объектов. Вторичный диспетчер объектов находит объект, расположенный вне пространства имен диспетчера объектов, в другом домене объектов. Простей­шим примером является система ввода-вывода.

Объект с именем Floppy0 — это объект-устройство, особый тип объектов, определяемый и используемый системой ввода—вывода. В пространстве имен диспетчера объектов объект-устройство отображает точку входа в домен объектов файловой системы, о котором диспетчер объектов ничего не знает.

При создании типового объекта "устройство" система ввода-вывода ре­гистрирует для него метод "разбор". Когда диспетчер объектов ищет имя объекта, он приостанавливает поиск, если ему встречается объект, имеющий метод разбора. Диспетчер объектов вызывает метод "разбор", передавая ему остаток имени объекта, которое нужно найти.

Например, когда процесс открывает описатель объекта с именем \Device\Floppy0\docs\resume.doc, диспетчер объекта проходит по своему дереву имен, пока не достигнет объекта-устройства с именем Floppy0. Он обнаруживает, что с этим объектом связан метод "разбор", и вызывает данный метод, переда­вая ему остаток имени объекта, которое он ищет — в данном случае строку \docs\resume.