/
Автор: Кастер Хелен
Теги: компьютерные технологии программирование операционные системы windows
ISBN: 5-7502-0023-Х
Год: 1996
Текст
МюювоЯ Press
Ri РУССКАЯ РЕДАКЦИЯ
УДК 681.3
ББК 32.973-01
К29
Хелен Кастер
К29 Основы Windows NT и NTFS/Пер. с англ. — М.: Издательский отдел “Русская Ре-
дакция” ТОО “Channel Trading Ltd.”, 1996. — 440 с.: ил.
ISBN 5-7502-0023-Х
Книга Хелен Кастер «Inside Windows NT» широко извест на среди специалистов
во всем мире. Опа создавалась в постоянном сотрудничестве с командой разра-
ботчиков самой ОС и позволяет читателю взглянуть изнутри на проект, филосо-
фию, архитектуру и будущее операционной сист емы Microsoft Windows NT.
В русском издании объединены две книги автора: «Inside Windows NT» и вышед-
шее чуть позже дополнение «Inside the Windows NT file system» (посвященное
файловой системе NTFS). В конце приведены общие для двух книг толковый
словарь терминов и предметный указатель. Материал книги богато иллюстриро-
ван. Издание дополнено в соответствии с современным уровнем ОС и с учетом
последней версии Microsoft Windows NT 4.0.
Книга рассчитана на специалистов и квалифицированных пользователей,
всерьез интересующихся современной мощной сетевой операционной систе-
мой Microsoft Windows NT.
© Оригинальное издание на английском языке, Inside Windows NT,
Microsoft Corporation, 1993
© Оригинальное издание на английском языке, Inside the Windows NT file system,
Microsoft Corporation, 1994
© Русский перевод, Microsoft Corporation, 1996
Подготовлено к печати издательским отделом “Русская Редакция” ТОО “Channel
Trading Ltd.” по лицензионному договору с Microsoft Corporation. Редмонд, Вашинг-
тон, США.
Microsoft, MS-DOS, Windows, Windows NT и эмблема Windows являются охраняемы
ми товарными знаками Microsoft Corporation в США и других странах. Все другие
товарные знаки являются собственностью соотвстствхтощих фирм.
ISBN 1-55615-481-Х (англ.)
ISBN 1-55615-660-Х (англ.)
ISBN 5-7502-0023-Х
Состав книги
Основы Windows NT
Предисловие...................................... 13
Введение ................................. ....... г/
ГЛАВА И
ПОСТАНОВКА ЗАДАЧИ........................... 21
ГЛАВА 2
ОБЩИЕ СВЕДЕНИЯ О СИСТЕМЕ.................... 33
ГЛАВА 3
ДИСПЕТЧЕР ОБЪЕКТОВ И КОНТРОЛЬ ДОСТУПА........... 65
ГЛ А В А 4
ПРОЦЕССЫ И ПОТОКИ............................... 95
ГЛ А В А 5
WINDOWS И ЗАЩИЩЕННЫЕ ПОДСИСТЕМЫ............ 123
ГЛАВА 6
ДИСПЕТЧЕР ВИРТУАЛЬНОЙ ПАМЯТИ .............. 169
ГЛАВА 7
ЯДРО............................................205
ГЛАВА 8
СИСТЕМА ВВОДА-ВЫВОДА............................237
ГЛАВА 9
СЕТЬ............................................2/5
Эпилог...........................................313
Библиография.....................................317
Основы файловой системы NTFS
Предисловие..........................................331
Введение ............................... .... . 333
ГЛАВА "1
ЗАЧЕМ ПОНАДОБИЛАСЬ ЕЩЕ ОДНА ФАЙЛОВАЯ СИСТЕМА?.. 335
ГЛАВА 2
МОДЕЛИ NTFS ................................ 343
ГЛАВА 3
СТРУКТУРА ФАЙЛОВОЙ СИСТЕМЫ..................351
ГЛАВА 4
ВОССТАНАВЛИВАЕМОСТЬ.........................363
ГЛАВА 5
УПРАВЛЕНИЕ ТОМАМИ И ОТКАЗОУСТОЙЧИВОСТЬ......377
ГЛАВА 6
СЖАТИЕ ДАННЫХ...................................387
ГЛАВА 7
ГЕНЕРАЦИЯ ИМЕН ФАЙЛОВ MS-DOS................393
Заключение.......................................397
Библиография.................................... 399
Толковый словарь.....................................401
Предметный указатель.................................433
Об авторе............................................437
windowsW
МююэаЛ
PRESS
HELEN CUSTER
® FOREWORD BY DAVID N. CUTLER
основы
WINDOWS NT
ХЕЛЕН КАСТЕР
ПРЕДИСЛОВИЕ ДЭВИДА И. КАТЛЕРА
Й.РУССШ РЕДАКЦИЯ
Взгляд изнутри на дизайн, концепцию, архитектуру и будущее
операционной системы Microsoft нового поколения.
Эта книга посвящается членам команды разработчиков Winclou's NT,
многие из которых внесли огромный личный вклад в проектирование
и создание этой операционной системы.
Долгих ей лет работы.
Содержание
Предисловие.......................................... 13
Введение............................................. 17
ГЛАВА 1
ПОСТАНОВКА ЗАДАЧИ.................................... 21
1.1 Операционная система 90-х годов.................. 22
1.2 Цели проекта..................................... 24
1.2.1 Расширяемость.............................. 25
1.2.2 Переносимость.............................. 26
1.2.3 Надежность................................. 28
1.2.4 Совместимость.............................. 29
1.2.5 Производительность......................... 30
1.3 Команда.......................................... 30
1.4 О других главах книги ........................... 31
ГЛАВА 2
ОБЩИЕ СВЕДЕНИЯ О СИСТЕМЕ............................. 33
2.1 Модели Windows NT................................ 34
2.1.1 Модельклиент-сервер........................ 34
2.1.2 Объектная модель........................... 39
2.1.3 Симметричная мультипроцессорная обработка.. 40
2.2 Структура Windows NT............................. 42
2.2.1 Защищенные подсистемы...................... 42
2.2.2 Исполнительная система..................... 44
2.2.3 Обзор основных понятий .................... 47
2.2.3.1 Сессия регистрации................... 47
2.2.3.2 Подсистемы среды..................... 49
2.2.3.3 Базовые сервисы...................... 50
2.2.3.4 Объекты.............................. 50
2.2.3.5 Виртуальная память .................. 53
2.2.3.6 Ввод-вывод и файловые системы........ 54
2.3 Другие детали архитектуры........................ 56
2.3.1 Интернационализация ....................... 56
2.3.1.1 Регионы.............................. 57
:новы WINDOWS NT
2.3.1.2 Unicode................................ 5g
2.3.2 Структурная обработка исключений.... ......... 60
2.4 Заключение.......................................... 64
ГЛАВА 3
ДИСПЕТЧЕР ОБЪЕКТОВ И КОНТРОЛЬ ДОСТУПА................... 65
3.1 Объекты исполнительной системы NT................... 65
3.1.1 Использование объектов........................ 67
3.1.1.1 Файловая модель........................ 69
3.1.1.2 Объектная модель....................... 70
3.1.2 Структура объектов............................ 72
3.1.3 Типы объектов ................................ 74
3.2 Управление объектами................................ 75
3.2.1 Имена объектов................................ 76
3.2.1.1 Каталоги .............................. 77
3.2.1.2 Домены ................................ 79
3.2.1.3 Символические связи.................... 80
3.2.2 Описатели объектов............................ 82
3.2.2.1 Удержание объектов..................... 84
3.2.2.2 Учет использования ресурсов............ 85
3.2.3 Методы объектов............................... 85
3.3 Защита объектов..................................... 87
3.3.1 Маркеры доступа............................... 89
3.3.2 Списки контроля доступа ...................... 91
3.3.3 Как все это работает вместе................... 92
3.4 Заключение.......................................... 94
ГЛАВА 4
ПРОЦЕССЫ И ПОТОКИ....................................... 95
4.1 Что такое процесс?.................................. 96
4.1.1 Адресное пространство......................... 96
4.1.2 Набор ресурсов................................ 98
4.1.3 Объект-процесс................................ 9?
4.2 Что такое поток?.................................... Ю1
4.2.1 Многозадачность и мультипроцесорная обработка. Ю?
4.2.2 Многопоточность...............................
4.2.3 Объект-поток.................................. 1$
4.2.4 Синхронизация................................ 110
содержание
4.2.5 Оповещения и асинхронные вызовы процедур..... 113
4.3 Структура процессов................................ 114
4.3.1 Требования подсистем среды . ................ 115
4.3.2 Базовая структура процессов.................. 118
4.3.2.1 Управление клиентскими процессами..... 119
4.3.2.2 Как предотвратить неправильное использование .. 121
4.4 Заключение......................................... 122
ГЛАВА 5
WINDOWS И ЗАЩИЩЕННЫЕ ПОДСИСТЕМЫ........................ 123
5.1 Общие сведения о защищенных подсистемах............ 124
5.1.1 Почему используется модель клиент-сервер? ... 126
5.1.1.1 Поддержка нескольких сред............. 127
5.1.1.2 Защита памяти......................... 130
5.1.2 Соображения производительности............... 132
5.2 Взаимодействие с подсистемами Windows МТ........... 136
5.2.1 Регистрация пользователя в системе........... 137
5.2.2 Выполнение приложений........................ 139
5.3 Подсистема Win32................................... 141
5.3.1 32-разрядный API............................. 143
5.3.2 Структура.................................. 145
5.3.3 Конструктивные изменения..................... 147
5.4 API MS-DOS и 16-разрядной версии Windows........... 152
5.4.1 Виртуальные DOS-машины....................... 154
5.4.2 Windows на Win32............................. 157
5.5 Передача сообщений при помощи механизма локального
вызова процедур........................................ 159
5.5.1 Объект-порт.................................. 160
5.5.2 Способы передачи сообщений LPC............... 162
5.5.2.1 Копирование в порт.................... 162
5.5.2.2 Передача через совместно
используемую память.................... 163
5.5.2.3 Обратные вызовы....................... 165
5.5.2.4 Быстрый LPC........................... 166
5.6 Заключение......................................... 168
ГЛАВА 6
ДИСПЕТЧЕР ВИРТУАЛЬНОЙ ПАМЯТИ.................... 169
6.1 Виртуальная память................................. 170
WINDOWS NT
6.2 Средство пользовательского режима.................. 1/
6.2.1 Управление памятью........................... 1>
6.2.2 Совместное использование памяти.............. 1)
6.2.2.1 Секции, проекции и проецируемые файлы .... d
6.2.2.2 Объект-секция........................ ig(
6.2.3 Защита памяти............................... 1g.
6.2.3.1 Собственная память процесса.......... 1g.
6.2.3.2 Совместно используемая память......... 1&
6.3 Реализация виртуальной памяти..................... 1g;
6.3.1 Адресное пространство....................... 1g;
6.3.2 Подкачка страниц............................. 1$
6.3.2.1 Механизмы подкачки страниц............ 1$
6.3.2.2 Стратегия подкачки и рабочие наборы.... 19;
6.3.3 База данных страничных фреймов.............. 19'
6.3.4 Дескрипторы виртуальных адресов............. 19?
6.3.5 Соображения мультипроцессорной обработки...... 20'
6.3.6 Соображения переносимости .................. 2tt
6.4 Заключение........................................ 202
ГА А В А 7
ЯДРО.................................................. 20‘
7.1 Общие сведения.................................... 20с
7.2 Планирование потоков.............................. 20/
7.2.1 Объекты процесс ядро и поток ядос........... 202
7.2.2 Приоритеты планирования..................... 21'
7.2.3 Переключение контекста...................... 212
7.3 Обработка прерываний и исключений ............... 212
7.3.1 Обработчик ловушки.......................... 212
7.3.2 Распределение прерываний.................... 21'
7.3.2.1 Типы и приоритеты прерываний......... 21-
7.3.2.2 Обработка прерываний................. 222
7.3.2.3 Программные прерывания................ 22
7.3.3 Распределение исключений..................... 22
7.3.4 Распределение вызовов системных сервисов.... 221
7.4 Многопроцессорная синхронизация................... 22£
7.4.1 Синхронизация на уровне ядра................. 2$
7.4.2 Синхронизация на уровне исполнительной системы .... 23<
7.5 Восстановление после сбоя питания ................. 2^
иидирдси nt?
7.6 Заключение........................................ 236
ГЛАВА 8
СИСТЕМА ВВОДА-ВЫВОДА ................................. 237
8.1 Общие сведения.................................... 238
8.1.1 Компоненты системы ввода-вывода............. 238
8.1.2 Особенности архитектуры..................... 240
8.1.2.1 Объектная модель NT.................. 240
8.1.2.2 Унифицированная модель драйвера...... 242
8.1.2.3 Асинхронная обработка................ 244
8.1.2.4 Проекционный файловый ввод-вывод
и кэширование файлов......................... 247
8.2 Обработка ввода-вывода ........................... 248
8.2.1 Файловые объекты ........................... 248
8.2.2 Запрос ввода-вывода к однослойному драйверу... 251
8.2.2.1 Посылка запроса ввода-вывода ........ 252
8.2.2.2 Обслуживание прерывания.............. 254
8.2.2.3 Завершение обработки запроса......... 256
8.2.3 Запросы ввода-вывода к многослойным драйверам. 258
8.2.4 Особенности использования асинхронного ввода-вывода. 262
8.3 Послойная модель драйвера......................... 264
8.3.1 Структура драйвера.......................... 264
8.3.2 Объект-драйвер и объект-устройство.......... 266
8.3.3 Пакет запроса ввода-вывода.................. 267
8.3.4 Функционирование многослойных драйверов..... 268
8.3.5 Вопросы разработки драйверов................ 270
8.3.5.1 Мультипроцессорная обработка......... 270
8.3.5.2 Восстановление после сбоя питания.... 273
8.4 Заключение........................................ 274
ГЛАВА 9
СЕТЬ.................................................. 275
9.1 Основы............................................ 276
9.1.1 История..................................... 277
9.1.2 Опорная модель OSI.......................... 278
9.2 Встроенная сетевая поддержка...................... 281
9.2.1 Сетевые API ................................ 282
9.2.2 Встроенные сетевые компоненты............... 285
9.2.2.1 Редиректор............................. 28б
9.2.2.2 Сервер................................. 2SR
9.2.3 Разрешение имен............................... 29Q
9.3 Открытая архитектура................................ 291
9.3.1 Доступ пользовательского режима
к удаленным файловым системам....................... 292
9.3.1.1 Маршрутизатор многосетевого
доступа для API WNet........................... 292
9.3.1.2 Многосетевой UNC для файлового
ввода-вывода Win32 ............................ 294
9.3.2 Транспортные протоколы........................ 296
9.3.3 Среда NDIS для сетевых драйверов ............. 298
9.4 Среда распределенных приложений .................... 300
9.4.1 Удаленный вызов процедур...................... 301
9.4.2 Именованные каналы ........................... 305
9.5 Корпоративные сети и распределенная защита.......... 307
9.6 Заключение.......................................... 311
Эпилог.................................................. 313
Библиография............................................ 317
ПРЕДИСЛОВИЕ
13 1965 году я окончил колледж со специализацией в математике (и, час тично,
в физике) и с огромным желанием быть инженером и "создава ть вещи”. Поэтому
я пошел работать в компанию DuPont в Уилмингтоне, штат Делавэр инженером
по прочностным испытаниям. После почти года полнейшей скуки я перешел в
группу математики и статистики, где получил задание разработать компьютер-
ную имитационную модель нового процесса производства пенопласта компа-
нии Scott Paper. Работать с машинами, которые никогда не делали того, что я от
них хотел, было тяжелым испытанием для моей гордости; через шесть месяцев
я попался на удочку, и компьютеры, которых я старался избегать со времен
окончания школы, стали делом моей жизни.
Вскоре после этого я перешел в инженерный отдел компании DuPont, где
программирование стало моей основной работой. У нас была небольшая ipyn-
па, создававшая управляющие компьютерные системы. Основным мотивом моего
перехода в эту группу было желание быть поближе к компьютерам; точнее же, я
хотел работать над созданием операционных систем (ОС). В составе эт ой группы
мне посчастливилось работать над несколькими автономными системами реаль-
ного времени; при эт ом приходилось заниматься как написанием цетральной
управляющей программы, выполнявшей планировку различных задач и монито-
ринг работы системы, так и кодированием реальных прикладных программ.
Скоро я понял, что заниматься разработкой серьезных ОС можно только в
компании, для которой компьютеры - основной бизнес. Так что в 1971 годуя
оставил DuPont и перешел на работу в Digital Equipment Corporation в городе
Мейнард, штат Массачусетс. Как оказалось, я занялся операционными система-
ми очень вовремя. Кто бы мог подумать, что мне повезет разрабатывать i ic-сколь-
ко ОС; ведь мало кому удается поучаствовать в разработке хотя бы од hoi i.
Моим первым проектом в области ОС была система реального времени
RSX-11М, которая работала на 16-разрядных миникомпьклерах PDP-11 фир-
мы DEC. В то время наши цели казались очень амбициозными. Нужно было со-
здать многозадачную ОС, которая работала бы на 32 Кбайт памяти, поддержива-
ла иерархическую файловую систему, подкачку приложи шй, планировку задач в
реальном времени и имела набор утилит для разработчиков. ОС и утилиты дол-
жны были работа ть па всех платформах серин PDP-11, от самых малых систем
floPDP-11/70, имевшей аппаратуру отображения адресов памяти и поддержи-
вавшей ОЗУ до -4 Мбайт.
У меня остались самые нежные воспоминания о том, как RSX-11М обретши
свои формы. Я завел резиновый штемпель, провозглашавший “Конечная цель —
это размер”, которым проштемпелевывал всю гцюсктную документацию подряд,
дабы быть уверенным, что все программисты и менеджеры проекта понимают
важность достижения наших целей. Тогда мы также познакомились с мощью
условного ассемблирования (вте годы использова! и ie языков высокого уровня для
создания ОС было лишь в зародыше), и когда кто-нибудь разрабатывал повое
средство, просто добавляли его как опцию при генерации системы.
При разработке RSX-11М большую часть времени мы проводили, изобре.
тая решения проблем памяти. Так как сис тема должна была работать па 32 Кбайт
мы разделяли весь запас памяти поровну между ОС и программами-утилитами
В результате для утилит осталось всего 16 Кбайт, и мы провели много часов
подгонкой оверлейных структур, обеспечивающих приемлемую производитель-
ность множества системных программ RSX-11М.
Хотя в случае RSX-11М требования к размеру и производительности были
иной раз очень строгими, из всех систем, над которыми я работал, опа была
вероятно, самой простой. Нужно было создать новую реализацию существую,
щей системы, но мы могли свободно менять и усекать интерфейсы программи-
рования — конечно, при условии, что прикладные программы можно было рс.
ассемблировать или перекомпилировать с минимальными изменениями исход-
ного текста. Система RSX—11М вышла в свет в 1973 году, через 18 месяцев после
начала работы. Она имела большой успех и помогла сделать PDP-11 самым по-
пулярным 16—разрядным миникомпыотером своего времени.
Компьютеры PDP-11 обеспечивали лучшее соотношение цена/произво-
дитслыюсть по сравнению с большими ЭВМ и могли использоваться на уровне
отделов предприятий. Вместе с другими популярными миникомпьютерами тех
лет они породили первую волну уменьшения размеров (downsizing) в компью-
терной индустрии. Уменьшение размеров было попыткой перенести приложе-
ния больших ЭВМ на миникомпыотеры. Многие такие приложения были слиш-
ком велики для PDP— 11. и почти сразу же Digital i шпала борьбу с тем, что Гордон
Белл (Gordon Bell) считал единственной самой важной причиной устаревания
компьют ерных архитектур — недостаточным количеством адресных разрядов.
Так родилась архитектура VAX, которая стала одной из наиболее популяр-
11ых архитектур конца семидесятых и сохраняла свои позиции все восьмидеся-
тые годы. Архитектура VAX обеспечивала 32—разрядную виртуальную адресацию
и устраняла необходимость втискивать программы в, казалось, постоянно со-
кращающееся адресное пространство.
Появление VAX предоставило мне возможность во второй раз участвовать
в разработке ОС Мне посчастливилось быть руководителем разработки ОС для
архитектуры VAX-11, результатом которой стала система VMS.
VMS была шорой системой разделения времени общего назначения фир-
мы Digital, разработанной специально для архитектуры VAX. Так как последняя
была непосредственной наследницей необычайно популярной архитектуры
PDP-11, теперь было необходимо обеспечить для приложений совместимость
лучшую, чем на уровне исходных текстов. В связи с этим в архитектуре VAX
имелся режим совместимости с PDP-11, в котором команды последней испол-
нялись непосредственно аппаратурой. В те времена казалось совершенно не-
вообразимым, что одна ОС поддерживает более одной среды “совместимости •
Хотя она и не была лучшей из известных ОС PDP-11 (это поразительно, по)
Digital было в разное время не менее десяти таких ОС!), все же именно RSX-11X'
была выбрана в качестве системного интерфейса, эмулируемого VAX в режпмс
совместимости с PDP-11. Для большинства людей за пределами компании тй1
решение, вероятно, было не очень понятно, но у RSX-11М был самый обшир"
ный набор средств разработки приложений; она имела большинство возмож-
ностей ОС общего назначения и поддерживала многозадачность; ее файлов}’11’
систему можно было расширить с сохранением совместимости. Наконец, VAX'
11 исполняла двоичный код RSX-1 IМ “как он есть”; это позволяло смонтировать
тома RSX—ИМ и обеспечить доступ к ним как программам, выполнявшимся в
режпмс совместимости RSX-11М, так и VAX-программам.
С технической точки зрения самой большой нашей ошибкой было то, что
мы писали VMS нс на языке высокого уровня. В то время у пас была группа очень
опытных программ истов па ассемблере, существовали некоторые строгие огра-
ничения по размеру и нс было компилятора, достаточно качественного для ге-
нерации кода ОС. Таким образом, чтобы гарантировать завершение работы над
системой в приемлемые с точки зрения рынка сроки, мы написали ее па ассем-
блере. Оглядываясь назад, все равно было бы трудно принять решение писать
VMS па языке высокого уровня. (Мораль: лучшее техническое решение — нс все-
гда лучшее с финансовой точки зрения.)
В начале восьмидесятых годов, пока миникомпыотеры были заняты “по-
глощением” приложений больших ЭВМ и новых программ, возникли две важ-
ных технологии: ncpcoi сальные компьютеры (ПК) и рабочие етаг 1ЦИ1i. По okoi i-
чании проекта VMS я несколько лет занимался разработкой компиляторов, пос-
ле чего возглавил группу, разрабатывавшую MicroVAX I — первую рабочую стан-
цию Digital серии MicroVAX.
Рабочие станции, такие как MicroVAX, обеспечивали высокопроизводи-
тельные вычисления однопользовательского режима для приложений типа сис-
тем автоматизированного проектирования (CAI IP); ПК использовались для биз-
пес-приложений индивидуального характера. Электронные таблицы и тексто-
вые процессоры — две ранних разновидности продуктов для ПК, имевшие боль-
шой успех. Хотя рабочие станции были относительно дороги, цены па персо-
нальные компьютеры были доступны для малого бизнеса.
Чтобы удовлетворять требованиям, в первых ПК использовали 8-разряд-
ные, а позднее 16-разрядные микропроцессоры. Им были присущи ограниче-
ния, сходные с имевшимися у RSX-11М, что требовало значительных усилий от
программистов и разработчиков ОС. Аппаратных ресурсов было настолько мало,
что основным назначением ОС была поддержка нескольких низкоуровневых
функций обслуживания аппаратуры и предоставление набора библиотек рабо-
ты с файловой системой. Однако персональные компьютеры обеспечили то,
чего не могли дать миникомпыотеры — рынок, на кагором независимые произ-
водители программного обеспечения могли продавать свои продукты в боль-
ших объемах. Результ ат ом явилось поистине удивительное количество и разно-
образие приложений для ПК.
В середине восьмидесятых годов микропроцессоры получили 32—разряд-
ную адресацию, чт о сразу стало использоват ься на рабочих станциях. Однако из-
за наличия очень большого количества ПК и приложений для них уже нельзя
было просто сделать новый компьютер, а нагом перекомпилировать для него все
прикладные программы У конечных пользователей ПК просто не было исходных
текстов программ, и они нуждались в совместимости на уровне двоичных кодов.
Летом 1988 года мне позвонил Билл Гейтс из корпорации Microsoft с инте-
ресным предложением. Он спрашивал, нс соберусь ли я приехать и поговорить
о создании новой ОС Microsoft для персональных компьютеров. В то время меня
не очень интересовала работа с персональными компьютерами, но я подумал,
что это хорошая возможност ь встретиться с Биллом и обсудить его идеи. То, что
предлагал Билл, сводилось к созданию новой ОС - переносимой и отвечающей
ОСНОВЫ WINDOWS NT
требованиям, которые предъявляются к ПК при выполнении критически в,га
ных задач.,(ля меня это был шанс создать стцс одну операционную систему1
В конце концов Билл убедил меня, что эту' возможность нельзя упуск.П|
так что в октябре 11>88 года я перешел в Microsoft и начал подбирать группу ,V;,
создания повой ОС. В то время я еще не понимал, что это будет самый амбицц
озный проект ОС, в котором я когда-либо участвовал.
Наши цели включали переносимость. защиту от несанкционированно!,
достепа, поддержку POSIX, совместимость, масш табируемую производители в м-р
(поддержку мультипроцессорной обработки), расширяемость и легкость инц-р
национализации. Из всех этих целей самой сложной и оказавшей нанболыне,
влияние па структуру ОС была совместимость. Сотни тысяч проданных си< 1е.
PDP-11 ничто по сравнению с десятками миллионов персональных компькис
ров! Мало того, мы должны были обеспечить совместимую поддержку'трех раз.
пых 16—разрядных сред и добавить новые 32—разрядные возможности, позвн
ляющие освободить приложения для ПК от ограничений виртуального адрепк,
го пространства, аналогичных существовавшим в PDP-11. И сверх всего. м);
хотели поддерживать стандартную спецификацию интерфейса UNIX под на
званием POS1X.
Теперь, спустя почти четыре года, мы близки к выпуску этой системы -
Windows NT — на рынок. Хелен Кастер (Helen Custer) приступила к работе на.
данной книгой тогда же. когда началась разработка системы. По мере развитп:
проекта книга подвергалась постоянным изменениям, отражая изменения в ар
хитектуре ОС. Это было трудной задачей — писать и переписывать различны
главы книги по мере развития проекта. Хотя идеи проекта принадлежат нам
Хелен выделяла их суть и делала их понятными нс только прос|х.-ссионалы1ьв
разработчикам ОС. За это мы все в большом долгу перед пей.
Нс представляется возможным упомянуть всех, кто сделал свой вклад в п|х>
скт Windows NT. Я обязан сказать, что нс я спроектировал се — я просто бы.
одним из участников этого. По мере чтения книги Вы познакомитесь с некого
рыми другими, но далеко не со всеми участниками. Система является результа
том усилий всей команды, и ее* разработка потребовала нескольких сотен чело
веко-лет. Возможно, самый важный вклад внесли те, кто занимался тсстирова
пнем системы. Без них Windows NT не смогла бы достичь сегодняшнего уровп!
качества.
Я надеюсь, что читать эту кишу о Windows NT будет для Вас' таким же уд<‘
вольствием, каким было для нас ее- разрабатывать.
Дэйн Kani'itf
руководите.1Ьразработки WindoirsЛ-
ВВЕДЕНИЕ
Д4ного воды утекло с тех пор, когда в 1980 году я нача ла писать эту кишу. Ничто
нс могло подготовить меня к тому всепоглощающему погружению в теорию,
проектирование и реализацию операционных систем, которое началось, когда
я решилась на это. 11режде чем начать, я перечитала кишу Трэйси Киддера (Tracy
Kidder) Soul of a Xew Machine (“Душа повой машины”), черпая в ней вдохновение
и ощущая родство по крайней мере с одним человеком, который прошел пред-
стоящий мне путь. Во многих отношениях создание Windows NT — это ’’про-
граммистская версия” процесса, описанного в книге* Киддера, и я подозреваю,
что мой опыт имеет некоторое сходство с сю.
Возможность создания повои OG, как и возможность создания новою ком-
пьютера, предоставляется далеко не каждому инженеру. Большинство специали-
стов по ОС па протяжении всей своей карьеры занимаются расширением или
модификацией существующих систем или созданием гаки х, разработка кото-
рых не доводится до конца ilhi которые никогда нс выходят на рынок. Компь-
ютерные фирмы регулярно ощущают финансовые или управленческие трудно-
сти, заставляющие их остановить разработку проекта. Те же системы, создание
которых все—таки доходи т до конца, часто не находят пиши на рынке пли ока-
зываются неприемлемы. так как существующие приложения требуют, чтобы
старые системы поддерживались вечно. Еще меньшее количество авторов име-
ют возможность написать книгу, подобную этой, описывающую разработку
принципиально повой ОС. Мне же посчастливилось сделать это.
В этой книге нет новинок теории. По большей части эта информация
уже была описана в различных формах, и часто более изящно, нежели уда-
лось мне. Однако моей целью было не написать учебник по принципам пост-
роения ОС (которые лучше изложены в других работах), но показать место
Windows NT средн других существующих систем. Хотя я и нс описывала зача-
стую весьма сложную логику проектных решений, но пыталась дать некото-
рое представление об истории ОС и исследованиях, повлиявших на оконча-
тельный вид Windows NT.
Книга нс предназначена для разработчиков ОС, которые, вероятно, хогсли
бы знать больше о внутреннем устройстве Windows NT, чем рассказано здесь.
Скорее, она для большинства из нас, кое-что знающих о компьютерах и желаю-
щих понять внутреннюю структуру эт ой системы, чтобы писать более качествен-
ные приложения или просто снять завесу тайны с черного ящика под названием
“опера।тонная система”.
Книга была закопчена за несколько месяцев до завершения работ над
Windows NT Поэтому некоторые описанные в пей возможности могут отсут-
ствовать в первой версии; одни мслуг быть отложены до следующих версий, дру-
гис — полностью исключены. Я, однако, пыталась представить общий взгляд на
Windows NT — нс расписывая “чудесное завтра" и не вдаваясь в подверженные
переменам детали реализации. Все описанное здесь либо уже имеется в составе
>СНОВЫ WINDOWS NT
системы. либо “придерживается" до того момента, пока не завершится тсстпр()
вание или пока не появится необходимое дополнительное программное обе(
печение. Некоторые темы были по необходимости опущены, так как либо ц,
разрабо тка началась слишком поздно, либо они будут документированы где -1(
еще. Другие темы, такие как защита от несанкционированного доступа и вц\ч
ренняя структура подсистем, освещены очень коротко. Примечательный пр,,
мер — подсистема Win32, обсуждаемая в гл. 5; описание се внутренних дст-алц
составило бы отдельный том. Вместо того, чтобы описывать Win32 API (что
делают другие авторы), эта киша рассматривает дизайн Windows NT и “стыкоц.
ку” Win32 и других APT с исполнительной системой N'T.
Kiihiv не обязательно читать от “корки до корки"; опа составлена так. чт(,
прочитав первые две главы, можно перейти к любому разделу. Однако теорстц
ческне понятия и термины имеют свойство наелапваткя друг па друга, так чч(
многие вещи станут яснее, если прочитать кишу от начала до конца.
За последние три года мне приишось разговаривать, расспрашивать, щ»
слущивать и спорить со многими людьми — все они заслуживают- моей благо
дарности. Я выражаю глубочайшую благодарность Дэйву Катлеру (Dave Cutlet-
который хотел, чтобы эта книга была написана, и /цел мне бсспрецсдстггпуто воз
можность сделать это. Его технические и редакционные замечания тоже был
очень полезны.
Я должна также горячо поблагодарить Лу Нераццоли (Lou Perazzoli) - един
ственного человека, читавшего все мои черновики, даже когда сто напряжений
расписание с трудом позволяло эчо делать. Без советов и поддержки Лу э та кии
га не появилась бы на свет.
Я выражаю особую благодарность Рону Бурку (Ron Burk) и 1эри Кимур
(Gary Kimura), подсказавшим мне, как организовать огромный .материал, собран
ный за время проекта. 11айти подходящую схему и втист iy-ть в нее описание сч»мп
многоплановой системы было одной из самых больших сложностей при работ;
над книгой.
Спасибо также программистам, которые позволили мне свободно займ
ствовать текст из их технических спецификаций и прояюгяли чернение, когда!
пыталась отобразить их видение системы с точки зрения “постороннего’’. Not
она, вероятно, написана нс так, как эчо сделали бы они, эта книга — в сущности
их книга; эчо четырсхлстняя хроника их радостей, тревог, разочарований1
вдохновения. Работать с ними и разделить их уникальный опыт было для мен
и наградой, и испытанием. Кроме тех, кто упомянут выше, особой благодарно
ч'и за техническую, редакционную и моральную поддержку заслуживают так*1
Дэррил Хэвенс (Darryl Havens), Стив Вуд (Steve Wood), Марк Лгоковскп (Мя**
Lucox sky), Джим Келлн (Jim Kelly), Скочт Людвиг (Scott Ludwig), Мэттью Фелтт’1
(Matthew Felton), Марк Збиковски (Mark Zbikowsky), Чандан Чаухан (Chand*
Chauhan), Чак Лснцманер ((Shuck Lenzmeicr), Мэри Хаттон (Mary’Hutton), ДсмУ
Фрей гаг (Asmas Freytag), Дэйв Томпсон (Dave Thompson). Лэрри Остсрмаг г (LJf'
Osterman), Санжай Джеюрпкар (Sanjay Jejurikar), Дэвид Гилман (David GilnKi':
Роберт Рэйчел (Robert Rcichcl), Чад Швиттерс ((Shad Schwitters), Брайан Уил'13'
(Bryan Willman), Юрик Капер (Eric Kutter), Ли Смит (Lee Smith), Стив Роув (Sid
Rowe), Пол Лич (Paul Leach), Брюс Хэйл (Bruce Hale), Роберта Лейбо!’11
(Roberta Leibovitz), Грегори Уилсон (Gregory Wilson), Дэвид Трэдвелл (Da'1'
введении
Treadwell), Садии Бхарати (Sudccp Bharati), Чак Чей (Chuck Chan), Мэнни Вейзер
(Manny Weiser), Лейер 11сдс|х’он (Leif Pederson). Дэн Хиисли (Dan Kinsley), Боб
Phiih (Bob Rinnc), Дэвид Мак-Брайд (David McBride), Ричард Барт (Richard
Barth), Джон Бальчупас ( John Balciunas). Рик Рашид (Rick Rashid). Tcpezta Стоуэлл
(Therese Stowell), Дэйв Харт (Dave Hart). Мэттью Брэдбери (Matthew Bradburn),
Кл1н|*Ь 14311 Дайк (Cliff Van Dyke). Лэвид Тэчер (David Thacher), Джейн Хоуэлл
(Jane Howell), Лорелей Зайферт (Lorelei Seifert), Боб Мутлиа (Bob Muglia) п Нол
Мории (Paul Maritz).
Моя персональная благодарность Колли Уилсон (Callie Wilson) за органи-
зацию внутреннего обращения этой книги и Карлу Сторку' (Carl Stork) за посто-
янное взаимодействие со мной по мере утечки сведений о рукописи. Для меня
было также огромным удовольствием работать с сотрудниками Microsoft Press,
включая Нэнси Сайдск (Nancy Siadck), Джеффа Кэри ( Jeff Carey), Дебору Лонг
(Deborah Long), Джудит Блох (Judith Bloch), Копни Литтл (Connie little), Кэтрин
Эриксон (Katherine Erickson), 11стги Херман (Peggy’ Herman), Джип Трииарп (Jean
Trenary), Барба Раньяна (Barb Runyan), Кима Эгглстоиа (Kim Eggleston), Уоллиса
Больца (Wallis Bolz) и Дина Холмса (Dean Holmes). Спасибо им за соблюдение
напряженного плана подготовки публикации и ту уверенность, с которой они
решали проблемы с этой большой и насыщенной деталями книгой.
Моя благодарность распространяется также на сотрудников библиотеки
Microsoft, подбиравших для меня все статьи и многие книги, использованные
мною в качестве основного и справочного материала. Они никогда не отвергали
мои запросы, даже самые невразумительные, и никогда не ругали меня за то, что
я ничего не возвращала вовремя. Я также должна выразить запоздалую благодар-
ность моему преподавателю пооперационным системам в Канзасском универси-
тете Дэниэлю Кана (Daniel (Запав), который зажег во мне интерес к ним и объяс-
нил мне, в чем значимость исследований.
На протяжении всей книги Вам будут встречаться имена авторов проекта
и разработчиков Windows NT. Многие из них здесь не упомянуты, но не нароч-
но; просто некоторые части ОС не описаны в книге, а в разработке некоторых
принимали участ ие слишком многие, чтобы можно было назвать всех. И, нако-
нец, хотя Дэйв Катлер упоминается в основном как разработчик ядра NT, он явля-
ется главным архитектором Windows NT и одним из наиболее продуктивных
кодировщиков. Почти все части ОС содержат написанный им код, iuiii, по край-
ней мере, выполнены в соответствии с его указаниями.
В хорошо спроектированной ()С сеть своя красота — четкий порядок, скры-
тый за бесконечными деталями реализации. Моей задачей было исследовать эту
большую программу и удалшъ достаточно много деталей, чтобы обнажился внут-
ренний порядок. Парадоксальный характер этого трудного предприятия, воз-
можно, лучше всего описывает следующая история.
В одни прекрасный день я сидела в офисе Лу Нераццоли, который объяс-
нял мне все входы и выходы (почти буквально) компонента урезания рабоче-
го набора, входящего в систему управления виртуальной памятью. Пока он
рассказывал, я внимательно слушала, складывая в голове подходящий для
книги упрощенный вариант. Когда он закончил, я рассказала ему, как пред-
ставляется только что услышанное с моей точки зрения, и спросила: “Пра-
вильно ли это?” Он совершенно серьезно ответил: “Да. это в точности что -
то вроде того, что мы делаем.”
СНОБЫ WINDOWS NT
В этой книге я балансировала между нагромождением точных детален
стройной обшей картиной. Как следствие. она описывает "в точности" что ,(j
вроде того, что было сделано разработчиками. Я должна поблагодари ть их .... )(j
что они поделились со мной своими знаниями и мыслями. За все ошибки г щ-.
ресказс этих знаний и мыслей отвечаю я.
.Хелен К. Кц. .
сентябрь •< <> -,
ГЛАВА i
ПОСТАНОВКА ЗАДАЧИ
в мире операционных систем колесо прогресса вращается ме/щснно. Разработ-
ка операционной системы (ОС) занимает годы. ) же созданная О(. остается бес-
полезной, пока не появятся приложения. позволяющие реализовать ее возмож-
ности. Потом ее еще предстои т осваивать, а для этого требуется докумен тация,
обучение и практика. Если учесть типичные задержки в разработке приложении
для ОС, это означает, что пользователи работают с системой, основанной на
технолопш 10- или 20-летней давности.
Пока ОС ожидают признания, аппаратные технологии идут вперед. Обыч-
ным делом становятся компьютеры с более мощным процессором, большим
объемом памяти и даже с несколькими процессорами. При этом разработчики
пытаются наспех усовершенствовать старые 1X3, чтобы те могли использовать
новые возможности.
Микросхемы Intel 80386 и 80-186 вместе со многими другими популярны-
ми процессорами относятся к разряду щюцсссоров со с.юмным набором ко-
манд (complex instructions set computers, ('ISC). Основная их особенность
большое количество сложных и мощных машинных команд. В последние годы
Intel достигла больших успехов в деле повышения производительности своих
процессоров, а другие фирмы разработали многопроцессорные машины с ис-
пользованием CISC-технологии от Intel.
В середине восьмидесятых годов появились процессоры с новым типом
архитектуры — процессоры с сокращенным наборам команд (reduced instruc-
tions set computers, RISC). Основное отличие таких микросхем от CISC в том, ч то
они предоставляют небольшое количество простых машинных команд. Благо-
даря этому процессоры RISC могут работа л, на более высокой тактовой частоте
и достигать очень большой cKoptxrn выполнения команд.
Многообещающие процессорные технологии быстро появляются как в
области CISC, так и в области RISC В Microsoft поняли, что для использования
этих и других новаций в технологии аппаратного обеспечения необходимо
создать ОС для О()-х годов, легко переносимую с одной аппаратной платформы
на друтую. Хотя в 80-х годах Microsoft и IBM разработали ОС OS/2, в Microsoft
считали, что у нее много сиранпчений; наиболее очевидное из них — отсутствие
переносимости. OS/2 была написана на языке ассемблера п 11редиазначалась для
компьютера с одним процессором Intel 80286. Вместо того, чтобы пытаться ка-
питал ьпо отремонтировать OS/2, Microsoft решила построить новую, переноси-
мую ОС “е нуля”.
ОСНОВЫ WINDOWS NT
1.1 Операционная система 90-х годов
Осенью 1988 1-ода Microsoft пригласила на работу Давида 11. Катлера (David у
Cutler), чтобы возглавить новый проект создания ОС Microsoft 90-х годов. Дэйв
известный специалист но системной архитектуре мпипкомпыотеров1 — бы<-ц>
собрал команду для разработки ОС Microsoft по повои технологии (NT). ]
начале 1989 года Билл Гейтс (Bill Gates) и основные разработчики стратег,,,
Microsoft собрались, чтобы обсудить спецификации ОС, составленные групп»,
Дэйва Катлера. Были сформулированы основные требования, предъявляемы,
рынком к новой ОС:
Переносимость. Новшества в аппаратном обеспечении возникают быстр,
и часто непредсказуемо. Например, RISC-процессоры существенноотличакпеж,
традиционных CISC. Написание NT на переносимом языке пояюлило бы быстр
переходить от одной архитектуры к другой.
Мультипроцессорная обработка и масштабируемость. 11еобходп.мс,
чтобы приложения могли использовать препму щества множества разновидное
гей компьютеров, известных в настоящее время. Например, компьютеры с не-
сколькими процессорами появляются на рынке регулярно, но лишь немногие и
существующих ОС могут в полной мере использовать их возможности. Созда
ние NT как масштабируемой многопроцессорной ОС позволило бы запуска!:
одно и то же приложение как на однопроцессорных, так и на мпогопроцессор
ных машинах. В предельном случае несколько приложений выполнялось 6t
одновременно с максимальной скоростью, а приложения, требующие большое
объема вычислении, могли бы повысить свою производителыкхть. распредели;
[заботу между несколькими процессорами.
Распределенные вычисления. В связи с гем, что в 80-е годы персе
налы пае компьютеры стали более доступными, характер вычислений необрати
мо изменился. Там, где раньше одна большая ЭВМ обслуживала всю фирму, те-
перь появились персональные компьютеры для рядовых служащих. Улучшений
возможности работы в сети позволили малым компьютерам связываться друг*
другом, зачастую совместно используя аппаратные или вычислительные ресур
сы (в форме файл-серверов, серверов печати и серверов вычислений). Учиты
вая эти изменения, разработчики NT планировали встроить функцию иоддерж
ки сети непос|х-дствснио в ОС и обеспечить приложениям возможность распре
делять работу между несколькими вычислительными системами.
Совместимость с POSIX. Во второй половине 80-х п»дов правительстве»’
пые учреждения США стали определять POSIX в качестве стандарта программ
пого обеспечения, поставляемого по правительственным контрактам. POS1X -
сокращение, которое расшифровывается как “переносимый интерфейс опер11
ционных систем, основанный на I’NIX” (portable operating system interface base*
on UNIX) — обозначает набор международных стандартов для иптерс|к*псов<)1
1 Др приход:! в Microsoft Дэйв Катлер пыл глинным консультантом в Digital Equipment
(Corporation, где проработал I* 7 В * дет. «дни маясь разработкой операционных систем и компилятор»»1’
В их числе (X. VAX/VMS. рабочая станция МктохАХ I и се ОС. ОС RSX-нм ,ия машины i’DI’ 11
а также компиляторы VAX 1’1..* I и VAX <-
Глава 1. Постановка задачи
UNIX-типа. Стандарт POSIX (стандарт IEEE 1003-1-198«) поощряет фирмы, ре-
ализующие UNIX-подобные интерфейсы, дс-лап. их совместимыми, чтобы про-
граммисты могли легко переноси ть свои приложения с одной системы на другую.
Чтобы удовлетворять требованиям к поставкам по заказам правителытва, NT дол-
жна была обеспечивать среду исполнения приложений POSIX.
Защита от несанкционированного доступа в соответствии с требо-
ваниями правительства США. Кроме совместимости с POSIX, правительст во
США устанавливает правила защиты для приложении, используемых в госучреж-
дениях. Прохождение правительст венной сертификации делает ОС конкурен-
тоспособной в данной сфере. Конечно, многие из требуемых правительст вом
средств полезны в любой многопользовательской системе. Правила защиты
включают обяза тельные требования, такие как защита ресурсов пользователя от
других пользова телей и возможност ь уст ановления кво т на сист емные ресурсы
для предотвращения захвата одним пользователем всех системных ресурсов
(например, памяти).
Изначально ставилось целью, чтобы система защи ты NT имела так называ-
емый уровень С2. определенный министерством обороны США как обеспечива-
ющий “селективное назначение прав доступа владельцем и, путем включения
возможностей аудита, учет субъектов и инициируемых ими действий”-. Это оз-
начает, что владелец системного ресурса может определя ть, кто имеет доспи к
ресурсу, и что ОС в состоянии определить, когда и кем была схуществлена по-
пытка доступа к ресурсу: Правительством США уст ановлены уровни защиты от 1)
(наименее строгий) до А (самый ст рогий), причем уровни В н С имеют несколь-
ко подуровней. Хотя первоначально NT создавалась для поддержки уровня за-
щиты С2, расширения в будущих версиях могут обеспечить выполнение более
строгих требований.
Из этих требований рынка и вытекала задача команды разработчиков NT:
создать ОС Microsoft 90-х годов. Первоначально предполагалось, что у NT будет
пользовательский интерфейс по тину OS/2, а интерфейс п/шк'шдных программ
(API) OS/2 станет основным интерфейсом программирования. Однако, когда
разработка системы была где-то на половине пути, вышла Microsoft Windows
3.0, имевшая мгновенный успех, — в отличие от OS/2, количеств) пользователей
которой было не слишком велико.
Учитывая требования рынка и сложность расширения и поддержки двух
несовместимых ОС, Microsoft решила нзмстпггь курс и направить всю энергию
на поддержку одной, последовательной стратегии развития ОС Эта стратегия
состоит в выпуске семейства Windows—подобных ОС для всех систем, начиная с
малых портативных компьютеров и закапчивая мощными мною процессорны-
ми рабочими станциями. Windows NT, как была названа Windows-система сле-
дующего поколения, заняла место во главе семейства Windows. Она имеет
Windows-подобный графический интерфейс пользователя и является первой
ОС корпорации Microsoft, предоставляющей Win32 API — 32-разрядный интер-
фейс программирования для разработки новых приложений. Win32 API предо-
ставляет приложениям все возможности ОС высокого уровня при помощи та-
ких средств, как многопоточные процессы, синхронизация, защита от несанк-
ционированного доступа, ввод—вывод и управление объектами.
Department of Defense Trusted Computer System Eraluatiou Criteria. !><»!) 5200.2Я.STD, Dccemlx-r IOK5.
ОСНОВЫ WINDOWS NT
СЕРВЕРЫ
Windows NT
Windows NT
OS/2 и
LAN Manager UNIX или
DOS/Windows Apple Macintosh
Windows NT
или OS/2
Windows NT
РАБОЧИЕ СТАНЦИИ
Рис. 1-1. Соединение разнородных систем.
Windows NT существует нс в вакууме. Она может взаимодействовать с др;
гимн ОС Microsoft, с Apple Macintosh и с UNIX-подобными ОС по сетям различ
него типа, в том числе Microsoft LAN Manager. Пример сетевой конфнгураци
показан на рис. 1-1.
В этой конфигурации серверы могут предоставлять системные средств,
такие как работа с файлами, печать или функции управления системами, либ
средства приложений, например, обслуживание баз данных. Приложение- моя»
даже обращаться к серверу для выполнения задач пользователя, хотя последим
и нс подозревает о таком взаимодействии. Сконфигурированная как ссрве[
Windows NT может служить многопользовательской сетевой ОС. Каждая Р:,б
чая станция может работа ть с одним интерактивным пользователем н песке»®
кпми удаленными, причем каждый пользователь (или приложение) должен ®
регистрироваться в системе, прежде чем получит доступ к ней.
1.2
Цели проекта
Проект Windows N T требовал пцателы юй iчредварителы юй ирстработки. Ч то*17
сис тема удовлетворяла требованиям рынка, кри тически важно с самого на4*’
было придать ей такие свойства, как поддержка POSIX и наличие защиты
Прежде чем начать писать несколько сотен тысяч строк кода, из котор1^
должна была состоять Windows NT. проектировщики системы тщательным •*
разом сформулировали цели щхх-кта. Предварительное определение целей 111
могло в принятии тысяч технических решении, задающих внутреннюю стру1'1;
ру большого программного проекта. При наличии двух альтернативных pel1’1
ний из них выбирали то, которое лучше отвечало этим целям.
I лава 'i. постановка задачи
Ниже перечислены свойства системы, которых стремились достпчьпроск-
тировщики Windows NT:
Я Расширяемость. Код должен быт ь написан так, чтобы его удобно было
дополнять и модифицировать при изменении требований рынка.
w 11ереносимость. В соответствии с требованиями рынка код должен лег-
ко переноситься с одного процессора на другой.
» Надежность и устойчивость. Система должна защищать себя как от внут-
ренних сбоев, так и от внешнего вторжения. Она должна всегда вести себя
предсказуемо, и у приложений не должно быть возможност и повредить
ОС или нарушить ее функционирование.
* Совмести си хть. Несмотря на то, что Windows NT призвана расширять
существующую технологию, ее пользовательский иптерс|х.-йс и API дол-
жны быть совместимы с сущест вующими системами Microsoft.
Производительност ь. Система должна отвечать другим целям проекта,
но при этом быть максимально быстрой и обеспечивать минимальное
время отклика па каждой аппаратной платформе.
В следующих разделах более подробно описаны те свойства системы, ко-
торые составили цель проекта Windows NT, а также их влияние па окончатель-
ный вид системы.
Л Расширяемость
Операционные системы обязательно изменяются с течением времени. Измене-
ния обычно вносятся постепенно; это может быть, например, добавление под-
держки новых аппаратных устройств, таких как компакт-диски; способности
работать с другим типом сети; поддержки новых программных технологий, та-
ких как фафнческие интерфейсы пользователя и обьектно-орист ггированные
среды программирования.
Гарантировать целостность кода Windows NT по мере изменения ОС с тече-
нием времени было основной целью проекта. Уникальный подход к решению
этой проблемы нашли для (XI Mach, разработанной в университете Карнет
Меллона, доктор Ричард Рашид и его коллеги: создать основу, которая реализует
примитивные средства ОС. Прикладные профаммы, называемые серверами',
обеспечивают дополнительные системные средства, включая полные API. При
изменении требований базовая част ь системы нс- меняется, а серверы модернизи-
руются или создаются новые.
Windows NT позаимствовала этот подход. Она стхтонт из привилегиро-
ванной исначните.чънпй системы (executive) и набора непривилегированных
серверов, называемых защищенными подсистемами (protected subsystems). Тер
мин привилегщмшанный указывает на режим работы процессора. Большинство
процессоров имеют привилегированный режим (возможно, несколько), в кото-
ром разрешено выполнение всех машинных команд и д< клуппы системные exxia-
Д.Чесь Термин “сервер” обозначает процесс па локальной машине, и его не следует iiviaii, с едален
ними компьютерами в ест. 11|х-доставляю11Ц1ми файловые или сетевые сервисы. Дальнейшую ни
Формацию см в гл 2.
НОВЫ WINDOWS NT
cm памяти, а также нсиривилстированный, в котором некоторые команды зап]
щены, а системные облает памяти недоступны. В терминологии Windows NT при.
вилегированный режим называегсл /хсмто/сн/яс)/*/ (kernel mode), а испрнвилс! ц.
рованный — пачьимшишьским /кжпмам (user mode).
Обычно ОС работает только в режиме ядра, а прикладные программы
только в пользовательском режиме, за исключением тех моментов, когда опг
вызывают системные сервисы. Однако Windows NT уникальна в том плане, ч п
ее защищенные подсистемы выполняются в пользователыко.м режиме, как ।
обычные приложения. Такая структура позволяет модифицировать или дехбаи
лять защищенные подсистемы, не нарушая целостности исполнительной систе-
мы (дальнейшую информацию см. в гл. 5. “Windows и защищенные подсистемы",
Кроме защищенных подсистем, Windows NT имеет- множество други?
свойств, гарантирующих ес расширяемость:
• Модульность. Исполнительная система представляет собой набор от
дельных компонентов, взаимодействующих друг с другом только ш.
средством функциональных интерфейсов. Новые компоненты добавля-
ются к исполнительной системе как новые модули, обращающиеся i
интерфейсам других компонентов.
• Использование объектов для представления системных ресурсе»
Объекты (objects), абст рактные типы данных, дехтуп к которым осуще-
ствляется только через специальный набор сервисов объектов, позво-
ляют однотипно управлять системными ресурсами. Добавление новы.'
объектов не нарушает работу старых и не требует изменения существую
щего кода (подробнее см. гл. 3, “Диенетчер объектов и контроль дехтупа”.
® Загружаемые драйверы. Подсистема ввода-вывода Windows NT поддер
живаст драйверы, которые мопт добавлячъся к системе в процессе ра
боты. Для поддержки новых файловых систем, устройств и сетей особ
ходимо написать драйвер устройства, драйвер файловой системы ii.ii
драйвер транспорта и загрузить сто в систему (см. гл. 8. “Система ввода-
вывода”, и гл. 9. “Сети”).
Средспю удаленного вызова процедур (RPC), позволяющее приложе-
ниям вызывать удаленные сервисы независимо от их расположения1
сети. Новые сервисы, установленные на любую машину в сети, немел
пенно становятся доступными для приложений на других машина'
(см. гл. О, “Сети”).
1.2.2 Переносимость
Вторая цель проекта — обеспечи л, переносимость тесно связана с расшир”
е.мостыо. Расширяемость позволяе т легко добавлять в систему новые возможно
сгн, тогда как переносимость обеспечивает использование всей ОС целиком н-
машине с другим процессором или конфигурацией при минимальных измене
нпях исходного -текста. Хотя (X; часто делят на “переносимые” и “ненсренос I’
мыс”, вообще говоря, переносимость в той или иной степени свойственна все'
им. Вопрос не в том, можно ли перенести программу (как правило, в конечно'
гчиг можно), а в том, насколько сложно это сделать.
Глава 1. Постановка задачи
Написание системы, которую легко будет переносить, сходно с написани-
ем любой перен<х'пмой программы — нужно следовать определенным прави-
лам. Во-первых. максимально возможный обт>с.м кода должен быть написан па
языке, доступном на всех машинах, па которые планируется переносить систе-
му. Обычно это значит, что код следует писать на языке высокого уровня, пред-
почтительно на одном из стандартизованных. Язык ассемблера по своей приро-
де нс переносим, если только Вы нс собираетесь переносить прелрамму исклю-
чительно на машины, обратно совместимые- с исходной по набору команд (на-
пример. с Intel 80386 па Intel 80486).
Во-вторых, следует учесть, в какие- физические среды планируется пере-
носить программное обеспечение. Любая аппаратура накладывает свои огра-
ничения на ОС. Например, ОС, разработанную для 32-разрядпой ад|х.сацпи,
не удастся перенести на машину с 16-разрядиы.ми адресами — разве что ценой
огромных усилии.
В-третьих, важно минимизировать и, где только возможно, вообще удалить
код, работающий непосредственно с аппаратурой. Аппаратурная зависимость
может принимать различные формы. Примеры очевидных зависимостей — пря-
мое манипулирование pet неграми и другими аппаратурными структурами либо
ориентация на некоторую аппаратурную конф|цурацию или емкость.
В-четвертых, везде, где аппаратурой—зависимого кода нельзя избежать,
его следует изолировать в небольшом количестве легко определяемых модулей.
Такой код еле,дует разбросать по всей системе.
Два последних правила тесно связаны друг с другом. Например, можно
скрыть аппаратурно-зависимую структуру в абстрактном типе,данных, опреде-
ленном в программе. Другие модули системы будут работат ь с этим типом дан-
ных посредством абстрактных процедур, а не напрямую с аппаратурой. При пе-
реносе ОС необходимо изменить только абстрактный тип данных и связанные
с ним процедуры.
Windows NT была спроектирована так, чтобы упростить ее переносимость.
Для этого использовали следующие подходы:
Переносимый язык С. Система написана в основном на языке С (стан-
дарт ANSI ХЗ.159-1989) с расширениями для поддержки архитектуры
обработ ки исключений Windows NT. Разработчики выбрали язык С, по-
скольку он стандарт:!! >ван, и для него широко доступны компиляторы и
средства разработки. I Iomiimo С, небольшие части системы написаны па
C++, в том числе графические комнонстггы среды Windows и фрагмен ты
сетевого пользоватслыкого интерфейса. Язык ассемблера использовался
только для тех частей (X', которые должны работать непосредственно с
оборудованием (например, обработчик ловушек), и для компонентов,
требующих максимальной скорости выполнения (таких, как целочис-
ленная арифметика повышенной разрядности). Однако непереносимый
код был тщательно изолирован внутри использующих его компонентов.
Изоляция от процессора. Некоторые низкоуровневые фрагменты ОС
должны работат ь с зависимыми от процессора структурами данных и
регистрами. Однако такой код содержится в небольших модулях, кото-
рые можно заменить аналогичными модулями для других процессоров.
Изоляция от платформы. Платформенно-зависимый код в Windows NT
иикйпеелипс ан hhvtdh динамически подключаемой библиотеки, из-
ОСНОВЫ WINDOWS NT
Главе 1. Постановка задачи
всей к >й как слон абст1х1ги1кмання от оборуЛмания (haidware alistr.ii•• к,
laver. HAL). 11лат<|юрмеиио—зависимыми называются свойства. к<>'i’< i«»i4
могут различаться па двух рабочих станциях, построенных па ощ
типе процессора, например MIPS К 1000. разными производите;! ч.,
HAL обеспечивает абстрагирование оборудования, например кэпц
контроллеров прерывании, при помощи слоя низкоуровневого н.„
гра.ммиого обеспечения, так что при переносе на другую платф >рм-. ,,
требуется изменять код более высокого уровня.
Windows NT написана так, чтобы облегчить ее перенос на машины и.
пользующие 32-разрядпую линейную адресацию и обеспечивающие подде| а;,
виртуальной памяти. Ее можно перенести п на другие машины, по это потреС:-
больших усилий.
1.2.3 Надежность
Третьей целью проекта Windows NT была надежность. Нод надежностью и<>, ,
зу.менаются два взаимосвязанных момента. Во-первых, ОС должна быть \ст<
чивой, дающей предсказуемый отклик i ia <»шиб< >4i пас состоят 1я, даже если < >н
вызваны сбоями аппаратуры. Во-вторых, СХ’должна активно защищать себ»
своих пользователей от вреда со стороны шхчьзовательскнх программ, случ.п
него или умышленного.
Структурная обработка исключений (structured exception handling:
это метод перехвата ошибочных состояний п унифицированной их обрабо н:
Она является основным способом защиты Windows NT от программных иле л
паратных ошибок. Всякий раз, когда возникает ненормальное событие. ОС ш
процессор возбуждают исключение; код обработки исключений, прнсутст..и
1ЦНЙ по всей системе, вызывается в таком случае автоматически, гарантируя mi
пользовательским программам и самой системе нс будет нанесен вред из-за i
обнаруженной ошибки (см. гл. 2, “Общие сведения о системе”).
Повышению устойчивоети способствуют и другие свойства ОС:
Модульная структура, разделяющая исполнительную систему на гр\ ::и
хо[хи|Ю организованных пакетов, с )тдельные компоненты системы н:-
имодействуют друг с другом через тщательно разработанные ;
раммные интерфейсы. Какой-либо компонент, например, днепст ч;
памяти, можно извлечь и заменить другим диспетчером памяти, |ха;и’
ющпм те же самые интерфейсы (см. гл. 2, “Общие сведения о с исте ме
Дтя Windows NT разработана н< >вая файловая система, называемая </> ••
ловой системой V/ (NT file system, NTFS). NTFS способна к восстан* >в и
нию после всех типов дис ковых ошибок включая ошибки в критичс.т
важных секторах диска. Для обеспечения восстанавливаемосто в псп
пользуется избы точное- храпение данных и обработка транзакций.
1кречис.лепные нижес|тедства защищают Windows NT от внешнего вторжси;|
Архитектура защиты от несанкционированною досгспа, основанная 1
требованиях правительства США, которая прсдостатояет разнообрази!'1
механизмы защшы: регистрация пользователей в системе, квоты на рее?:
сы н защита объектов (см. гл. 5, “Windows и защищенные подсистемы"
“ Ниртуатная намять (virtual memory), предоставляющая кажцой про-
грамме большой обчем адресного пространства. При обращении про-
граммы по виртуальным адресам .диспетчер памяти отображает (транс-
лирует) их в настоящие- адреса памяти. Гак как 0(2 управляет располо-
жением в памяти каждой программы, опа предотвращает чтение или
изменение одним пользователем памяти, занимаемой другим пользова-
телем. если только они явно нс* объявили ее совместно используемой
(см. гл. 6, “Диспетчер виртуальной памяти”).
1.2.4 Совместимость
Совмс-сти.мсхть программного обеспечения четвертая цслы|роекта Windows NT
— это сложный вопрос. В (Х'новно.м под совместимостью понимают способность
ОС выполнять 1 ipeяраммы. nai uicai в 1ые для другой < Х2 или для 1 цх дыдуЩ! ix версий
той же самой системы. В Windows NT совместимость имеет несколько форм.
Существует разница межху двоичной совместимостью и совместимостью
па уровне исходных текстов приложений. Двоичная совместим! >стъ достигается
тогда, когда можно взять некоторый исполняемый файл и успешно запустить
его в другой (XI Совместимость на уровне исходных текстов требует предвари-
тельной перекомпиляции программы.
Будет ли новая (Х2 двоично совместима со старой или совместима с ней па
уровне исходных текстов, зависит от нескольких факторов. Главный среди них -
это архитектура процессора новой системы. Если новый процессор использует
тот же набор команд (возможно, с расширениями) и ту же адресацию, что и
старый, то может достигаться двоичная совместимость.
Добиться двоичной совместимости между двумя процессорами разных
архитектур пс- столь просто. Каждая процессорная архитектура обычно песет с
собой новый машинный язык. Это означает, что двоичная совместимость дости-
гается только при помощи программы-эмулятора. преобразующей один набор
машинных команд в другой. При отсутствии эмулятора все приложения, перено-
симые* со старой архитектуры, должны быть заново скомпилированы и скомпо-
нованы (и, вероятно, вновь отлажены).
При помощи защищенных подсистем Windows NT предоставляет среду
для выполнения приложений, которые используют API - интерфейс, отличный
от ее основного интерфейса программирования Win32. При работе на процес-
сорах Intel защищенные подсистемы Windows NT обеспечивают двоичную со-
вмесгимость приложениям для существующих (Х2 Microsoft, включая .MS-DOS,
10—разрядную Windows, OS. 2 и LAN Manager. На RISC—процессорах MIPS совмести-
мость на двоичном у|хтвне дсхтиглстся для приложений .MS-DOS. 16- разрядной
Windows' и LAN Manager (используется эмулятор). Кроме того. Windows NTooecne-
* Для обеспечения совмеешмек in Io p.i грядных приложений для W nxlow* па компыоюрлх с RISC
процессорами используется эмуляция работы процессоров Intel. До версии <51 включи 1илыю
эмулировал» »! режим работы 2В6 -го процессор.!. что пс позволяло исполнять многие К»разряд
пыс приложения (например. Word lor Windows (>.0) Начиняя с версии 4,п обеснсчивапся эмуля-
ция p.ioolbl нроцс»-сор J. 410 ДОС-ИН очно для выполнения ООЛЫИИНСПЫ рЛ!рЯДИЫХ Про
грамм для W’mdows
{Примечи!Hie. символами * во всей гппге отмечены примечания и дополнения, сделанные научным
консультантом киши)
Ы WINDOWS NT
inner совместимость на уровне исходных текстов дтя приложений POSIX, кото-
ыс используют POSIX-нптерфсйсы (М3, определенные стандартом IEEE 1003.1
В дополнение к совместимости по программным интерфейсам. Windows
Т поддерживает ряд существующих (файловых систем, включая файловую си<
;му MS-DOS (FAT), высокопропзводшпе.чьиую файкмую систему (1IPFS) OS 2”,
чиповую систему для компакт-дисков (CDF'S), а также новую, восстанавлнва-
пук» (файловую систему NT (N i l'S).
роизводительность
[оследней целью п|юекта Windows NT было достижение высокой пропзводп-
ельности. Приложения с большим объемом вычислений, такие как графичес-
ие пакеты, средства моделирования и пакеты финансового анализа требуют
остаточно высокой пршзводителыкхти, чтобы обеспечить пользователю хо-
ошее время отклика. Одного быстродействующего оборудования для этого не
остаточно. ОС гоже должна быть быст рой п эффективной.
Производительность постоянно имелась в виду при разработке всех ком-
юнептов Windows NT. Проводилось тестирование и моделирование быстродей-
ствия компонентов, критичных для производительности системы. Системные
ызовы, страничные ошибки и другие критические участ ки вычислений гща-
сльно оптимизировались для достижения максимальной скорости обработки
см. гл. 6, “Диспетчер виртуальной памяти”, и гл. ”. “Ядро”).
Защищенные подсистемы, серверы, которые выполняют функции 0(3,
должны часто вз.шмодействовать друг с друзом и с приложениями-клиентами.
1тобы это взаимодействие не снижало производительность серверов, в состав
)С был включен высокоскоростной механизм передачи сообщений, так на.зы-
1аемый.7ОАТ47ы/ы/7 вызов процедур (loc al procedure call, i.P(3) (см. гл. I, “11роцес-
:ы и потоки”).
Каждая защищенная подсистема, обеспечивающая среду (ХЗ, или подсчс-
пема среды (environment subsystem), была тщат ельно спроектирована, чтобы
састо используемые системные вызовы выполнялись как можно быстрее (см.
л. 5, “Windows и защищенные подсистемы”).
Критические компоненты сетевой поддержки Windows NT для улучшения
1роизводитслы1(хтп были встроены в привилегированную часть 0(3. Несмотря
а это, они могут загружаться и выгружаться динамически (см. гл. 9, “Сети")
Когда-то несколько человек могли уединиться и через несколько месяцев су-
масшедшей работы “выдать” новую ОС- По времена изменились.
Современная ОС должна удовлетворять множеству требований нового
>борудования. например, поддерживать несколько сетевых протоколов. не-
сколько процессоров, несколько файловых систем и постоянно возрастаютсс
число устройств ввода—вывода. Помимо этих требований, система будет бес-
полезной, если к пей нет разнообразного программного обеспечения (бпб
В Windows XT Персии t.O <|»aici<»ir.i>i система HPI’S не и<>.Цсржиц-.ц“1ся.
IAOBO 1. I lOCTdHOBKO ЗОДС1ЧИ
лнотек, графического интерЦх’йса пользователя, утилит и приложений), не го-
воря уже о документации.
Группа, создавшая исполнительную систему NT и первые защищенные
подсистемы, была относительно небольшой •- около 10 человек в начале и, ве-
роятно, 10 или 50 па следующих стадиях проекта. С некоторыми разработчика-
ми <Х' Вы познакомитесь далее. Эти люди играли ключевые роли в проекте, ио
они не смогли бы добиться успеха без помопси многих других. Разработчики
утилит Windows NT приложений и драйверов устройств, те, кто отвечал за пере-
нос системы, тестеры программного обеспечения, руководители проектов,
ipvnna маркетинга и вспомогательный персонал — в общей сложности участни-
ков проекта насчитывалось более 200 человек. В итоге создание Windows NT
пот ребовало огромных усилии многих людей.
1.4 О других главах книги
Вторая глава начинается с общего обзора Windows NT, моделей, лежащих в ее
основе, и компонентов системы. В каждой из последующих глав рассматривает-
ся отдельный компонент, его важнейшие характеристики, основные аспекты
проектирования и взаимодействие с другими компонентами. Обсуждение сис-
темы идет “от середины к краям”: си io начинается в центре с процессов и объек-
тов, перемещается вверх к защищенным подсистемам и средам API, после чего
поворачивает вниз к управлению памятью, ядру, системе ввода-вывода н сетям.
ГЛАВА 2
ОБЩИЕ СВЕДЕНИЯ О СИСТЕМЕ
С?перационная система — это компьютерная программа, обеспечивающая сре-
ду для выполнения других программ и облегчающая им доступ к возможностям
процессора и устройств ввод-вывода, таких как диски. ОС очень удобна, по не
абсолютно 11еобходима для работы с компьютером. На заре компьютерной эпо-
хи техники загружали программы в память, используя прими тивные устройства
ввода: кнопки и переключатели или перфоленты. Затем они вручную задавали
стартовый адрес программы и указывали компьютеру, что надо перейти к нему
и начать ее выполнение. Однако современные пользователи компьютеров при-
меняют более совершенные методы.
Сешд! 1яшние ОС 11редоставляют пол ьзователям два вида услуг. Во-первых,
они упрощают использование аппаратных средств компьютера. Создаваемая
ими “виртуальная” машина заметно отличается от реальной. На самом деле ком-
пьютерная революция последних двух десятилетий произошла, в частности,
благодаря тому, что ОС смогли вполне успешно изолировать пользователей от
непонятной им аппаратной части компьютеров. Кроме того, npoi раммистам
больше не надо переписывать приложения для каждою нового компьютера.
to-вторых, ОС обеспечивают распределение вычислительных ресурсов между
пользователями. Од, вн из самых важных ресурсов — время процессора. В многоза-
дачной (multitasking) ОС, такой как Windows NT, bi лполнясмая работа подразделяет-
ся на гЦхщессы (processes), каждому из которых гцтедоставлястся память, системные
ресурсы и по крайней мере один потокуЩхжпения (thread of execution) — исполня-
емая единица внутри процесса. ОС выполняет один поток в течение короткого ин-
тервала времени, после чего переключается на другой. Многозадачность очень по-
лезна даже в однопользовательской системе, так как позволяет компьютеру выпол-
нять две задачи одновременно. Например, пользователь может редактировать один
документ, в то время как компьютер в фоновом режиме печатает другой или компи-
лирует большую прО1рамму. Каждый из процессов выполняет свою задачу, а для
пользователя это выгладит так, как будто все программы работают одновременно.
Кроме обеспечения совместного использования процессора, ОС распре-
деляет память 11 управляет доступом к файлам и устройствам. ОС различаются гю
способам, которыми они представляют виртуальную машину пользователям и
распределяют между ними ресурсы. Способ, применяемый в Windows NT, и бу-
дет предметом обсуждения в остальной части книги.
В первом разделе данной главы рассматриваются модели, оказавшие вли-
яние на окончательный вид ОС. Второй раздел — это беглый обзор ее внутрен-
ней структуры. Третий раздел от тсывает еще две частл i общест югемтюй apxi ттек-
туры: интернационализацию и структурную обработку исключений.
Модели Windows NT
Операционная система — эго сложная щхярамма, в которой детали накладыва-
ются друг на друга. В сущшхти, “оркестровка” этих деталей, обчединение мно-
жества битов и бай тов в связную структуру является одной из самых важны х
задач при создании ОС. Чтобы система могла обеспечивай» желаемые возмож-
ности, нс нарушая целей проекта, необходима унифицирующая модель.
Что такое модель ОС? Словарь определяет модель как “предварительное
описание системы или теории, учитывающее все известные ее свойства”1. Модель
ОС — это каркас, который связывает в единое i tcnoe все средства и сервисы, обес-
печиваемые системой, с одной стороны, и выполняемые ею задачи, с другой.
Структура Windows NT основана на комбинации нескольких моделей.
Модель клиент-сервер (client/server) служи т в Windows NT для того, чтобы предо-
ставить пользователям различные среды ОС (исходно Windows, MS-DOS, OS/2 и
POSIX), а объектная модель (object model) — д ля унификации управления систем-
ными ресурсами и выделения их пользователям. Третья модель, симметричная
м^пътипроцесарная обработка (symmetric multiprocessing, SMP), позволяет
Windows NT максимально использовать возможности многопроцессор! iwx машин.
Модель клиент-сервер
Существует множество способов структурирования кода ОС. Один подход, осо-
бенно часто применяемый в небольших ОС, например в MS—IX)S, состоит в
организации системы как набора процедур, каждую из которых может вызывать
любая пол»»зовательская процедура. Такая монолитная структура не обеспечива-
ет изоляции данных; в разных участках кода используется информация об уст-
ройстве всей системы. Расширение ОС этого тала затруднительно, так как изме-
нение некоторой процедуры может вызвать ошибки в других частях системы, на
первый взгляд нс имеющих к ней отношения.
Во всех монолитных ОС, кроме самых простых, приложения отделены от
собственно ОС. Иными словами, код ОС исполняется в привилегированном ре-
жиме процессора — в этой книге он называется режимом ядра (kernel mode) и
имеет доступ к данным системы и к аппаратуре; приложения исполняются в
непривилегированном, так называемом пользовательском режиме (user mode),
в котором им предоставлен ограниченный набор интерфейсов и ограниченный
доступ к системным данным. Когда программа пользовательского режима вызы-
вает системный сервис, npoi teccop перехватывает вызов и переключает вызыва-
ющий поток в режим ядра. Когда выполнение системного вызова завершается.
ОС переключает поток обратно в пол»>зовательский режим и дает возможность
вызывающей программе продолжить выполнение. Структура монолитной ОС с
разделением пользователккого режима и режима ядра показана на рис. 2-1.
Другой подход к структурированию системы предполагает разделение се на
модули, наслоенные один поверх другого. Каждый модуль предоставляет набор
функций, которые могут вызываться другими модулями. Код, расположенный р
некотором слое, вызывает код только из нижележащих слоев. В некоторых
1 “A tentative description of a system or theory that accounts tor all its known properties.” American
Heritage Dictionary, 2 cd. (Boston. Houghton Mifflin Company; I9«5).
1 QB
z. иищие
Рис. 2-1. Монолитная операционная система.
например, в VAX/VMS и в старой Multics, многослойность даже принудительно
обуславливается аппаратурой (посредством использования иерархии режимов
процессора). Одна из возможных послойных структур показана на рис. 2-2.
Одним из преимуществ послойной организации ОС являеюя то, что код
каждого слоя получает доступ только к необходимым ему интерфейсам (и
структурам данных) нижележащих слоев; таким образом уменьшается обтсм
кода, обладающею неограниченной властью. Кроме тою, такая структура позво-
ляет при отладке ОС начинать с самого нижнего слоя и добавлять по одному
уровню до тех пор, пока вся система не станет работа л, правильно. Послойная
структура обличает и расширение системы; можно целиком заменить любой
уровень, не затрагивая остальных частей.
Третий подход к структурированию ОС — это модель клиент-сервер. Идея
его состоит в разделении (М2 на несколько процессов, каждый из которых реа-
лизует один набор сервисов: например, распределение памяти, создание про-
цессов или планирование процессов. Каждый сервер (server) выполняется в
пользовательском режиме, проверяя в цикле, нс обра тился ли к нему за обслужи-
ванием какой-либо клиент2. Клиент (client), которым может быть либо другой
компонент ОС, либо прикладная программа, запрашивает выполнение сервиса,
’ некоторые ОС, такие как Qouds и BiiN (см. библиографию), работают по-другому, используя для вы-
полнения серверного кода вызывающий поток, но предварительно переключая адресное пространство.
юсылая серверу сообщение. Ядро (или микроядро) ОС, выполняющееся в режц-
ле ядра, доставляет сообщение серверу; тот выполняет запрашиваемые дсй-
твия, после чего ядро возвращает клиенту результаты в виде другого сообщу
1ия. как показано на рис. 2-3.
При использовании клисю-серверного подхода получается ОС, сехтоя-
цая из автономных компонентов небольшою размера. Поскольку все серверы
наполняются как отдельные процессы пользовательского режима, авария (и
зозможно, перезапуск ) одного из них нс нарушает работы остальных частей
XI Более тою, разные серверы могут выполняйся на разных процессорах мно-
гопроцессорного компьютера или даже на разных компьютерах, что делает (зр
пригодной для распределенных вычислительных сред.
Теоретическая модель, показанная на рис. 2-3, — это идеализированное
изображение системы клиент-сервер, где ядро состоит только из средств пере-
дачи сообщений. В действительности существует целый спектр клиент-сервер-
ных систем, часть которых выполняют в режиме ядра малый объем работы, в то
время как другие — больший. Например, ОС Mach, один из современных приме-
ров клиезгг—серверной архитектуры, имеет ядро минимальною размера, в функ-
ции которою входит планирование потоков, передача сообщений, управление
виртуальной памятью и драйверы устройств. Все остальное, включая различные
интерфейсы прикладных программ (API), файловые системы и сетевую поддер-
жку; работает в пользовательском режиме.
В структуре Windows NT есть элементы как послойной, так и клиент-се|>
верной модели. Часть Windows NT, работающая в режиме ядра, называется ис-
полните.п.ъиой системой /УТ (NT executive). В нее входит набор компонентов,
Рис. 2-2. Послойная операционная система.
1лава 2. Общие сведения о системе
Посылка сообщений ----►
Ответ----------------->
Рис. 2-3. Клиент-серверная операционная система.
реализующих управление виртуальной памятью, управление обтс-ктами (ресур-
сами), ввод—вывод и файловые системы (включая сетевые драйверы), взаимо-
действие методу процессами и фрагменты системы защиты от несанкциониро-
ванного доступа. Эти компоненты взаимодействуют между собой главным обра-
зом как модули, а не как слои. Каждый компонент вызывает другие посредством
набора тщательно оговоренных внутренних процедур.
Однако послойная модель применяется в системе ввода-вывода исполни-
тельной системы NT, описываемой далее, и в самых низкоуровневых частях ис-
полнительной системы: ядре NT (NT kernel) и слое абстрагирования от обору-
дования (hardware abstraction layer, HAL). Все другие компоненты исполнитель-
ной системы NT расположены поверх этих двух. Ядро NT выполняет функции
ОС низкого уровня, похожие на те, с которыми мы встречаемся в клиелгг—сер-
верных ОС с микроядром — например, планирование потоков, обработку пре-
рываний и исключений, а также многопроцессорную синхронизацию. Оно так
же предоставляет набор процедур и базовых обкктов, используемых остальны-
ми частями исполнительной системы для реализации конструкций более высо-
кого уровня. Ниже ядра располагает ся динамически подключаемая библиотека
(dynamic-link library, DLL) HAL — слой кода, изолирующий ядро и другие части
исполнительной сист емы NT err платформенно-зависимых особенност ей аппа-
ратуры. ILAL рабо тает непосредственно с оборудованием.
Как показывает рис. 2-4, модель клиент-сервер используется в Windows
NT главным образом для предоставления API и средств, которые обычно рас-
сматривают как среду ОС. Хотя защищенная подсистема (сервер) Win32 обеспе-
чивает пользовательский интерфейс и необходима для работы системы, другие
серверы также могут подключаться к исполнительной системе, причем они мо-
Ы WINDOWS NT
yr загружаться и выполняться одновременно в любо!i желаемой комбинации
ерверы взаимодействуют с процессами приложений при помощи средства
средами сообщений, предоставляемого исполнительной системой NT.
Использование модели клиент-сервер дает следующие преимущества:
Упрощает базу ОС — исполнительную систему NT. Одной из задам Win-
dows NT было предоставить API Win32, MS-DOS, 16—разрядной Win-
dows, POSIX и OS/2. Реализация каждого API в отдельном сервере устра-
няет конфликты и дублирование в исполнительной системе и позволя-
ет легко добавлять новые API.
Повышает надежность. Каждый сервер выполняется как отдельны!"11ipo-
i iecc, имеющий собствс! тую память, и, таким образом, защищст i от дру-
гих процессов. Более тою, гак как серверы работают в пользователье-
ком режиме, они не имеют* непосредственного дехггупа к аппаратуре и
не могут изменить содержимое областей памяти, занятых нсполнитель-
1 юй системой.
Прекраа ю соответствует модели распределишых вычислений. Так как
сетевые компьютеры используют модель клиент—сервер и общаются
друг с другом посредством передачи сообщений, локальные серверы
легко могут посылать сообщения удаленным машинам при обработке
запросов от клиентских приложений. Клиентам не требуется знать, об-
служивается их запрос локально или удаленно.
Посылка сообщений -----*
Ответ------------------>
Рис. 2-4. Клиент-серверная структура Windows NT.
Глава 2. Общие сведения о системе
2.1- 2 Объектная модель
В своей книге “Создание объектно-ориентированною программного обеспе-
чения” Бертран Мейер (Bertrand Meyer) характеризует ОС как программы, “над
которыми ничего неггГ (“have no top”)'. Как и в случае других больших про-
граммных систем, трудно найти одну “главную программу”, которая управляет
всей ОС. Таким образом, вместо тою, ччобы разрабатывать такую систему сверху
вниз, по объектно-ориентированной методологии сначала рассматривают дан-
ные, с которыми должна работать программа для выполнения своей задачи. Для
ОС такими данными являются системные ресурсы — файлы, процессы, блоки
памяти и т. д.
Основная цель разработки системы с ориентацией на данные — это созда-
на ie программною обеспечен! 1я, которое можно было бы ле! ко (и дешево) изме-
нять. Насколько важна способность к модификации, становится ясно, если при-
нять во внимание часто приводимую статистику, согласно которой 70% цены
программных продуктов падает на сопровождение. Сопровождение включает в
себя введение новых возможностей, модификацию форматов данных, исправле-
ние ошибок и адаптацию к новому оборудованию.
Один из способов минимизации необходимых изменений в объектно-
ориентированных программах — это сокрытие физического представления
данных внутри объектов. Объект (object) — это структура данных, физический
формат которой скрыт в определении типа. Он имеет набор свойств, называе-
мых ат[шбутами (attributes), и с ним работает группа сервисов.
Хотя Windows NT не является в строгом смысле объектно—ориентирован-
ной системой (как определяет эго понятие Мейер), она использует объекты для
представления системных ресурсов. Каждый системный ресурс, который могут
совместно использовать несколько процессов, — файлы, память и физические
устройства — реализован как объект и обрабатывается обчектными сервисами.
Такой подход уменьшает влияние изменений, которые могут происходить в си-
стеме с течением времени. Например, если изменение в ОС вызвано изменением
в аппаратуре, то необход! imo 1вменить только обчект, представляюгщ !Й данный
аппарат! 1ый ресурс, и его сервисы; код, кочорый использует объект, не нуждает-
ся в модификации. Аналогично, если нужно ввести в систему поддержку нового
устройства, создается новый обч>ект, и добавление его к системе не нарушает
существующего кода.
Помимо того, чго уменьшается влияние изменений, построение ОС на ос-
нове объектов имеет еще ряд несомненных преимуществ:
Доступ ОС к ресурсам и работа с ними унифицированы. Создание, уда-
ление и ссылка на объект-событие осуществляется так же, как и для
объекта—процесса: с использованием описателей (handle) объектов. И
поскольку каждый ресурс — эго объект, контроль использования ресур-
сов сводится к отслеживанию создания и использования объектов.
® Упрощается защита, так как для всех объектов она осуществляется од! та-
ково. При попытке доступа к объекту подсистема защичы вмешивается
и проверяет допустимость операции, независимо от тою, является ли
' Bertrand Meyer, Object-Oriented Software Construction (Hertfordshire, United Kingdom: Prentice-Hall
International. 1988), 47.
объект процессом, секцией совместно используемой памяти или ком-
му| ткационпым портом.
Объекты предоставляют удобную и унифицированную парадигму для
совместного использования ресурсов двумя или несколькими процес-
сами. Для работы с объектами любого типа используются описатели
объектов. Два процесса совместно используют объект тогда, когда каж-
дый из них открыл его описатель. ОС может отслеживать количество
описателей, открытых для данного объекта, чтобы определить, дейст-
вительно ли он все еще используется. После этого система может уда-
лить объекты, которые более нс используются.
В гл. 3, “Д1юпстчер объектов и koi ггроль доступа”, описан диспетчер объек-
тов — компонент исполнительной системы NT, отвечающий за реализацию и
травление объектами Windows NT
Симметричная мультипроцессорная обработка
ногозадачность — это техника, применяемая ОС для использования одного
процессора несколькими потоками управления. Однако, если у компьютера
имеется более одного процессора, то от модели многозадачности следует пе-
рейти к модели мультипроцессорной обработки (multiprocessing). Компьютер,
имеющий два процессора, может выполнят два потока одновременно. Таким
эбразом, если многозадачная ОС только создает иллюзию одновременного вы-
полнения нескольких потоков, то ОС с мультипроцессорной обработкой в дей-
ствительности выполняет несколько потоков одновременно — по одному пото-
ку на каждом процессоре.
ОС с мультипроцессорной обработкой делятся на две категории — с асим-
метричной либо симметричной обработкой, как показано на рис. 2—5.
Операционные системы с асимметричной мультипроцессорной обработ-
кой (asymmetric multiprocessing, ASMP) обычно выбирают для исполнения соб-
ственного кода один и тот же процессор (например А), в то время как другие
процессоры выполняют только пользовательские задачи. Так как код ОС испол-
няется на одном процессоре, то ОС ASMP довольно просто создать, усовершен-
ствовав существующую однопроцессорную ОС. Особенно хорошо ОС ASMP
подходят для работы на асимметричном оборудовании, например, процессо-
ре, к которому подключен сопроцессор, или на двух процессорах, совместно
использующих нс всю доступную память. Однако такую ОС трудно сделать пе-
реносимой. Аппаратура разных производителей (и даже разные версии аппа-
ратуры одного производителя) имеет тенденцию различаться по типу и ст епе-
ни асимметрии. Либо производители оборудования должны ориентироваткя
на одну ОС, либо ОС придется постоянно переписывать для каждой аппарат-
ной платформы.
Системы с симметричной мультипроцессорной обработкой (symmetric
multiprocessing, SMP), к которым относится и Windows NT, позволяют коду
системы выполняться на любом свободном процессоре или на всех п|х>цссс°-
рах одновременно, причем каждому из процессоров доступна вся память. Тако*1
подход полнее реализует возможности нескольких процессоров, так как сам;1
ОС может Iктюльзовать значи тельную часть процессорного времени компыотС'
ра, в зашichmoctu оттого, какие приложения па нем исполняются. Исполнение
ОС только на одном процессоре может сильно загружать его, в то время как
остальные простаивают, что уменьшит производительность системы; при увели-
чении числа процессоров в системе возрастает вероятность того, что узким
местом станут именно действия, выполняемые ОС. Помимо равномерного рас-
пределения системной загрузки, системы SMP сокращают время простоя из-за
неисправностей, гак как при сбое одного процессора код ОС может исполня ть-
ся на других. Наконец, поскольку симметричная аппаратура реализуется разны-
ми производителями сходным образом, имеется возможность создания перено-
симой ОС SMP.
В отличие от ASMP. системы SMP обычно проектируются и пишутся полно-
стью заново, так как, чтобы гарантировать правильную работу. их код должен
следовать строгим правилам. Конкуренция за ресурсы н другие вопросы произво-
дительности принимают в мультипроцессорных системах более острую форму,
чем в обычных ОС. и должны усчитываться при проектировании системы.
Windows NT обладает свойствами, которые принципиально важны для
мультипроцессорной ОС:
в Код ОС может выполняться на любом из доступных процессоров и на
нескольких процессорах одновременно. За исключением ядра, которое
выполняет планировку потоков и обработку прерываний, весь код ОС
может быть вытеснен (принужден к освобождению процессора) пото-
ком с более высоким приоритетом.
Асимметричная
Симметричная
Устройства ввода-вывода
Процессор А
Операционная
система
Процессор Б
Устройства ввода-вывода
Рис. 2-5. Асимметричная и симметричная мультипроцессорная обработка.
В одном процессе может быть несколько потоков управления. Потоки
позволяют процессу выполнять разные части сто программы на не-
скольких процессорах одновременно1.
Серверные процессы могут использовать несколько потоков для одно-
временной обработки запросов от нескольких клиентов.
Имеются удобные механизмы совместного использования объектов
разными процессами и гибкие возможности коммуникаций между про-
цессами, включая совместно используемую память и оптимизирован-
ное средство передачи сообщений.
Процессы и потоки описываются в гл. 4, “Процессы и потоки”; серверы
Windows NT описаны в гл. 5, “Windows и защищенные подсистемы”.
Структура Windows NT
структурно Windows NT можно разделить на две части: одна работает в пользо-
вательском режиме (защищенные подсистемы Windows NT), а другая — в режи-
ме ядра (исполнительная система NT). Подробно структура Windows NT изобра-
жена на рис. 2—6.
Серверы Windows NT называются защищенными подсистемами (protected
>ubsystems), так как каждый из них — это отдельный процесс, память которого
кпцищена от других процессов системой виртуальной памяти исполнительной
системы NT. Так как совместное использование памяти подсистемами не рсали-
«уется автоматически, то коммуникации между ними осуществляются путем пе-
эедачи сообщений. Сплошные линии па рис. 2—6 обозначают пути передачи
сообщений между клиентом и сервером или между' двумя серверами. Вес сооб-
цения проходят через исполнительную систему, но для простоты па рисунке
ио не показано.
Как уже говорилось выше, 1 ктюлнптельная система NT — это “ды шатсль” ОС,
способный поддерживать любое число серверных процессов. Серверы предостав-
1яют исполнительной системе NT пользовательские и программные интерфейсы,
i также обеспечивают среды для выполнения приложений разных типов. В слсду-
ощгух двух разделах структура Windows NT рассматривается более подробно.
Защищенные подсистемы
Гермин “сервер” подразумевает, что каждая защищенная подсистема обеспечи-
вает API, который могут использовать программы. Когда приложение (или ДРУ'
ой сервер) вызывает некоторую процедуру API, серверу, реализующему данну|О
гроцедуру; посылается сообщение при помощи средства локального вызова
гроцедур (local procedure call, LPC) оптимизированного механизма исполни'
ельной системы NT для локальной передачи сообщений. Сервер же посылает
цветное сообщение вызывающей программе.
Когда речь идет о многопоточном процессе, легче написать “выполняется процесс”, нежели “вы
юлнястся поток процесса”. Таким образом, в этой книге иногда говорится о процессе, запрашиваю
цсм память или генерирующем исключение. но Вы должны понимать, что в Windows NT к действ*1'
слыюсти всегда выполняется поток (некоторого процесса).
В Windows NT имеется дватипа защищенных подсистем: подсистемы сре-
ды (environment subsystems) и неотъемлемые подсистемы (integral subsystems).
Подсистема среды — это сервер пользовательского режима, реализующий API
некоторой ОС. Когда приложение вызывает функцию API, этот вызов доставля-
ется посредством LPC подсистеме среды. Та исполняет вызов и возвращает ре-
зультаты прикладному процессу, посылая другой LPC.
Самая важная подсистема среды в Windows NT — это подсистема Win32,
которая предоставляет прикладным программам API 32-разрядной Windows.
Кроме того, подсистема среды Win32 реализует графический интерфейс поль-
зователя Windows NT и управляет всем вводом пользова теля и выводом прило-
Приложения
Передача сообщения---------------->
Системная ловушка-----------------►
Взаимодействие с оборудованием----►
Рис. 2-6. Блок-схема Windows NT.
ений*. В Windows NT также имеются подсистемы среды POSIX, OS/2, 16-раз-
ядной Windows и MS-DOS (две последние не показаны на рис. 2-6). Данные
одсистемы предоставляют свои API, по используют для получения пользова-
гльского ввода и отображения результатов подсистему Win32.
Другие защищенные подсистемы - неотъемлемые подсистемы это сер-
фы, выполняющие важные функции ОС. В процессе разработки Windows NT
екоторые неотъемлемые подсистемы появлялись и исчезали, но одна присут-
гвовала всегда: подсистема защиты. Подсистема защиты исполняется в пользо-
ательском режиме и регистрирует правила контроля доступа, определенные
пя локального компьютера. Например, она отслеживает, какие учетные записи
ользователей имеют особые привилепш, доступ к каким системным ресурсам
одлежит аудиту и должны ли генерироваться сообщения или предупреждения
Гдита. Кроме того, подсистема защиты ведет базу данных учетных записей
ользователей, содержащую идентификаторы пользователей, пароли, труппы, к
эторым отнесен пользователь, и особые привилегии, которыми он обладает,
'на также принимает регистрационную информацию пользователя и иниции-
ует аутентификацию подключения пользователя к системе.
Некоторые компоненты сетевого обеспечения Windows NT также реалнзо-
1ны как защищенные подсистемы. Заслуживают упоминания две из них: сервис
абочей станции и сервис сервера. Каждый из этих сервисов (services), как часто
азывают сетевые подсистемы, является процессом пользовательского режима,
еализующим API для доступа и управления, соответственно, сетевым редирект-
ором и сервером LAN Manager. Редиректор — это сетевой компонент, ответ-
гвенный за посылку запросов ввода—вывода по сети, если файл или устройство,
которому осуществляется обращение, не является локальным. На удаленной
ашине такие запросы принимаются сервером. И редиректор, и сервер LAN
[anager реализованы как драйверы файловых систем — т. е. являются частью
тстемы ввода-вывода NT, описываемой далее.
1сполнительная система
сполнительная система NT (NT executive) — это часть Windows NT, исполняю-
тся в режиме ядра; за исключением пользовательского интерфейса, опа сама
э себе является законченной ОС. Исполнительная система состоит из ряда ком-
энептов, причем каждый из них реализует два набора функций: системные сер-
1сы, к которым могут обращаться как подсистемы среды, так и компоненты
сполнительной системы, а также внутренние процедуры, доступ! иле только ком-
энентам исполнительной системы. Эти интерфейсы изображены на рис. 2- ~
Хотя исполнительная система и предоставляет системные сервисы, похо-
ие на API, она фундаментально отличается от подсистем среды. Исполнитсль-
ая система не исполняется постоянно в собственном процессе, а работай"! в
энтексте некоторого существующего процесса, завладевая выполняющимся
этоком, когда происходит важное системное событие. Например, когда поток
язывает системный сервис и перехватывается процессором, или когда внеш-
ес устройство вызывает прерывание процессора, ядро получает управление
I .чанном предложении подразумевается. что модули управления окнами и выводом на зкрап рас
хлагаклея в подсистеме Win32. Однако, начиная с версии Windows NT-Ц). они перенесены в нс
>.'1нпчельнею систему NT для повышения И|ХЯ1 чвод|ггслы|ости.
потоком, который выполнялся процессором. Оно вызывает соответствующий
системный код для обработки события, выполняет его и затем возвращает уп-
равление коду, выполнявшемуся перед прерыванием.
Компоненты исполнительной системы поддерживают независимость друг
от друга, для чего каждый из них создает необходимые системные структуры
данных и работает с ним. Так как интерфейсы между компонентами тщательно
контролируются, можно полностью удалить некоторый компонент и заменить
другим, работающим иначе. Если новый компонент корректно реализует все
системные сервисы и внутренние интерфейсы, то ОС работает как прежде. Со-
провождение ОС также упрощается, поскольку компоненты исполнительной
системы NT взаимодействуют предсказуемым образом.
Ниже перечислены различные компоненты исполнительной поемы и их
области ответственности:
Диспетчер объектов. Создает, поддерживает и уничтожает объекты ис-
полнительной системы NT — абстрактные типы данных, представляю-
щие системные ресурсы.
Справочный монитор защиты. Гарантирует выполнение политики за-
щиты на локальном компьютере. Оберегает ресурсы ОС. обеспечивая
защиту объектов и аудит во время выполнения.
Диспетчер процессов. Создает и завершает процессы и потоки. Кроме
того, приостанавливает и возобновляет исполнение потоков, хранит и
выдает информацию о процессах и потоках NT.
Средство локального вызова процедур (LPC). Передаст сообщения меж-
ду клиентскими и серверными процессами, расположенными на одном
и том же компьютере. LPC — это гибкая, оптимизированная версия уда-
Диспетчер
процессов
диспетчер
объектов
Справочный
монитор
защиты
Средство
локального
вызова
процедур
Диспетчер
виртуальной
памяти
Диспетчер
окон(USER)
GDI*
Диспетчер
Ввода-вывода
Драйверы
графических
устройств
U'
Ядро
Слой абстрагирования от оборудования (HAL)
Системные сервисы
Внутренние интерфейсы
' Только начиная с Windows NT версии 4.0
Рис. 2-7. Системные интерфейсы.
ленного вызова процедур (remote procedure call, RPC), средства комму.,
никации между клиентскими и серверными процессами по сети, являю,
щегося промышленным стандартом (подробнее см. гл. 9, “Сети”).
® Диспетчер виртуальной памяти Реализует виртуальную память (vir_
tual memory, VM) — схему управления памятью, которая предоставляет
каждому процессу’ большое собственное адресное пространство и за-
щищает это пространство от других процессов. Если память использу-
ется слишком интенсивно, то диспетчер виртуальной памяти персг го
епт содержимое выбранного блока памяти на диск г г загружает обрат-
но, когда он снова понадобится. Такая практика называется подкачкой
страниц (paging).
* Ядро. Реагирует на прерывания и исключения, направляет потоки на
выполнение, выполняет межпроцессорную синхронизацию и предос-
тавляет набор элементарных объектов и интерфейсов, используемый
остальными частями исполнительной системы NT для реализации
объектов более высокого уровня.
Система ввода—вывода. Состоит из группы компонентов, отвечагогцих
за выполнение ввода—вывода на разнообразные устройства. В систему
ввода—вывода входят следующие подкомпоненты:
□ Диспетчер ввода—вывода. Реализует средства ввода—вывода, не зави-
сящие от типа устройства, г г устанавливает модель для ввода -вывода
исполнительной системы NT.
□ Файловые системы. Драйверы NT. принимающие запросы файлово-
го ввода—вывода и транслирующие их в запросы, привязанные к кон-
кретному устройству.
□ Сетевой редиректор (network redirector) и сетевой сервер (net-
work server). Драйверы файловой системы, передающие удаленные
запросы ввода—вывода на машины в сети г г принимающие от них
такие запросы.
□ Драйверы устройств исполнительной системы NT. Низкоуровневые
драйверы, напрямую работающие с оборудованием для записи вы-
вода или считывания ввода с физических устройств или с cent.
□ Диспетчер кэггта. Повышает производительность файлового ввода-
вывода, сохраняя информацию, считанную с диска последней, в си-
стемной памяти. Диспетчер кэша использует средство подкачки
страниц диспетчера виртуальной памяти для автоматической запи-
си информации гга диск в фоновом режиме.
’э Слой абстрагирования от оборудования (HAL). Помещает кодовую про-
слойку между исполнительной системой NT и аппаратной платформе!'-
на которой работает ОС. Скрывает аппаратно-зависимые детали, такие
как интерфейсы ввода-вывода, контроллеры прерываний и механизм'’1
межпроцессорных связей. Вместо того, чтобы обращал,ся к аппаратуре
непосредственно, исполшггельная система NT сохраняет максималь-
ную переносимость, обращаясь к функциям HAL, когда ей нужна плат-
форменно-зависимая информация.
Windows NT — это переносимая ОС, разработанная так, чтобы ограничить
объем кода, который зависит от конкретной архитектуры оборудования. Тем нс
менее, некоторый объем такого кода необходим; он располагается на самых
нижних уровнях ядра NT плюс небольшие порции в диспетчере виртуальной
памяти. Эти компоненты, особенно ядро NT, скрывают процессорные различия
от остальной части ОС
Код, зависящий от платформы, — т. е. от способа реализации некоторым
производителем, например, компьютера MIPS R4000 - располагается в HAL и
поставляется самими производителями компьютеров. Драйверы устройств со-
держат, конечно, код, зависящий от устройства, но избегают кода, зависящего от
процессора или платформы, вызывая процедуры ядра NT и HAL.
2.2.3 Обзор основных понятий
Windows NT (за малыми исключениями) нс кажется пользователю совершенно
новой ОС. Она похожа на Windows и может выполнять приложения для нее.
Однако то, что скрыто за интерфейсом пользователя, радикально отличается от
Windows. В следующих разделах дается беглый обзор того, как разные части
Windows NT стыкуются друг с другом, начиная с пользовательского интерфейса
и двигаясь вниз к исполнительной системе NT.
2.2.3.1 Сессия регистрации
Windows NT — это защищенная ОС, требующая, чтобы у каждого пользователя
была учетная запись и чтобы пользователь регистрировался в системе, прежде
чем получить доступ к ней. Учетная запись каждого пользователя связана с про-
филем защиты, который представляет собой набор информации, относящейся к
контролю доступа и хранящейся в системной базе данных. Подсистема защиты,
используя эту информацию, проверяет, действительно ли пользователи являют-
ся теми, за кого они себя выдают. Компоненты системы, участвующие в регист-
рации пользователя, показаны на рис. 2-8.
Процесс системы защиты, называемый процессии регистрации в системе
(logon process), ожидает ввода от пользователя. Могут быть активны одновре-
Пользовательский
режим
Локальный вызов процедуры (LPC)
Рис. 2-8. Регистрация в системе.
ВЫ WINDOWS NT
Поскольку подсистема Win32 обрабатывает весь вывод на дисплей, тс > д]д,_ f
гие подсистемы должны перенаправлять видеовывод своих приложений снеге- t
ме Win32 для отображения. VDM, исполняющая приложения 16-разрядпой ।
Windows, транслирует вызовы видеовывода своих приложений в вызовы Winy?
и посылает их в виде сообщения системе Win32. Подсистемы OS/2 и POSIX. рав-
но как и VDM, в которых исполняются приложения MS-DOS, перенаправляют
системе Win32 символьный вывод своих приложений, который последняя ото-
бражает в окнах символьного режима, называемых консолями (consoles).
Подсистема среды может поддерживать много клиентских приложений
Каждая подсистема отслеживает своих клиентов и поддерживает глобальную
информацию, которую они используют совместно. Хотя одновременно могут
выполняться несколько подсистем и VDM, Win32 является единственной подси-
стемой среды, видимой пользователю. С его точки зрения, все приложения вы-
полняются системой Windows.
Базовые сервисы
Подсистемы С|юды реализуют свои API, обращаясь к базовым сервисам (native
services) — системным сервисам, предоставляемым компонентами исполнитель-
ной системы NT. Например, диспетчер виртуальной памяти обеспечивает серви-
сы выделения и освобождения памяти, а диспетчер процессов — сервисы созда-
ния и завершения процессов и потоков. Как показано на рис. 2—11, когда подси-
стема вызывает базовый сервис NT, аппаратура детектирует этот вызов и переда-
ет управление исполнительной системе NT. После этого выполнение сервиса
осуществляется в режиме ядра.
Так как базовые сервисы используются различными подсистемами среды,
то они должны быть универсальными и даже примитивными. Они должны
быть гибкими н не иметь лишних ограничений. Наконец, базовые сервисы не
должны вызывать побочных эффектов, которые мопт конфликтовать с разно-
образными потребностями подсистем среды.
Одгп 1м из способов достижеш 1я п 1бкосп I базовых серы icon coctoi it в tom.
что они способны работать с любым процессом, заданным вызывающей про-
граммой. В вызове задается описатель процесса, и сервис выполняет дейст вия
над заданным процессом. Например, подсистема может вызвать базовый сервис
для того, чтобы создать поток гит выделить память для одного из своих процес-
сов-клиентов. Конечно, большинство обычных процессов нс могут выполнять
подобные действия с другими процессами. Подсистемы среды обладают мощ-'
ными маркерами доступа, дающими им власть над их клиентами.
Основными пользователями базовых сервисов являются защищенные под-
системы DLL и компоненты исполнительной системы NT Приложения, испол-
няемые под Windows NT, написаны для одного 113 программных i штерфспсов —
Win32, MS-DOS, 16—разрядной Windows, POSIX или OS/2, которые реализу-
ются подсистемами среды.
Объекты
Многие, возможно, большинство из базовых сервисов NT — это объектные сер'
псы. Иными словами, они выполняют некоторое действие над объектом в на-
полнительной системе NT Поток открывает описатель объекта и затем исподь-
|ует этот описатель при вызове сервисов, работающих с объектом.
Системная ловушка------>
* Только начиная с Windows NT версии 4.0
Рис. 2-11. Вызов базового системного сервиса.
Ресурсы, поддерживающие совместное использование, включая процессы,
потоки, файлы и распределяемую память, реализованы в исполнительной систе-
ме NT как объекты. Таким образом, ОС может воспользоваться сходством
свойств ресурсов и использовать общий код для работы с разными типами ре-
сурсов, где только возможно. Объектная система NT — это центральная точка
выполнения различных задач управления ресурсами, таких как именование ре-
сурсов; установка пределов, так называемых квот (quotas) объема ресурсов, ис-
пользуемых процессом; совместное использование ресурса двумя процессами и
защита ресурсов от несанкционированного доступа.
Подсистемы среды часто вызывают объектные сервисы для создания, от-
крытия описателя, манипулирования или удаления объектов. Так, при запуске
пользователем какого-либо приложения Win32, например Microsoft Excel, под-
система Win32 вызывает диспетчер процессов NT для создания процесса (в ко-
тором будет исполняться Excel) и получения его описателя. В свою очередь,
диспетчер процессов вызывает диспетчер объектов, чтобы создать объект— про-
цесс и объект—поток. Аналогично, при сохранении пользователем новой табли-
цы Excel подсистема Win32 обращается к диспетчеру ввода-вывода NT, чтобы
создать файловый объект, представляющий файл, в котором хранится электрон-
пая табл! ща, и открыть описатель этого объекта. Диспетчер ввода—вывода обра-
щается для выполнения этой задачи к диспетчеру объектов. Данный процесс ил-
люстрируется рис. 2—12.
Основной объем обработки, связанной с управлением ресурсами, осуществ-
ляется в NT тогда, когда некоторый процесс создает объект и/или открывает опи-
сатель объекта. Например, когда процесс (в нашем случае подсистема VCin.Sjy
создает объект, он может (но необязательно) задать имя объекта. Присвоение
объекту имени делает возможным совместное использование этого объекта не-
сколькими процессами. Процесс, желающий использовать распределяемый
объект, просто выбирает его имя, обращаясь к диспетчеру объектов NT, и затем
открывает описатель объекта.
Объекты размещаются в памя п i OG Чтобы предотвратить захват одн! im про-
цессом слишком большого объема памяти, с него списывается определенный
объем выделенной процессу квоты всякий раз, когда один из его потоков открыва-
ет описатель объекта некоторого типа. Если процесс израсходовал всю свою киоту,
то диспетчер объектов больше не позволит ему открывать описатели объектов.
Помимо управления ресурсами и поддержки их совместного использова-
ния, объектная система NT служит центром, в котором обеспечивае тся защита
ресурсов. При открытии процессом описателя объекта активизируется подсис-
тема защиты NT. С каждым объектом связана маленькая база данных, называемая
списком контроля доступа (access control List, ACL) и содержащая информацию
о том, какие процессы имеют доступ к объекту и какие действия эти процессы
могут над ним производить. При открытии описателя объекта процесс указыва-
ет, какие действия он собирается производить с объектом. Например, процесс
Рис. 2-12. Создание объектов МТ.
тлили z. сэощие снедения о системе
может открыть файл для доступа по чтению. Система защиты проверяет, предо-
ставлен ли процессу доступ по чтению к данному файлу, и если это так, то дис-
петчер объек тов возвращает процессу описатель, имеющий доступ по чтению.
Процесс может затем использовать этот описатель для чтения соответствующе-
го файла. Если процессу необходим также доступ по записи, то он может либо
запросить оба вида доступа при открытии первого описателя, либо открыть
вто[х;й описатель с доступом по записи. В силу' того, что процесс должен от-
крыть описатель объекта, прежде чем он сможет что-либо с объектом сделать,
и того, что в открытой описателя участвует подсист ема защиты, ни одни про-
цесс не может обойти контроль доступа NT.
2 2.3-5 Виртуальная память
Разные ОС по-разному представляют физическую память и требучот от своих
программ доступа к ней по определенным правилам. В Windows NT приклад-
ные программы исполняются в одной из сред, которые ведут себя как некото-
рая ОС: Windows, MS-DOS, POSIX или OS/2. Задача состоит в том, чтобы при-
ложения всех типов могли выполняться без изменений и без столкновении
друг с другом в памяти.
Каждая подсистема среды Windows NT представляет память в том виде, ко-
торый ожидают от нее приложения. Исполнительная система NT, лежащая ниже
подсистем среды, имеет свою собственную структуру памяти, к которой подси-
стемы обращаются, вызывая базовые сервисы NT.
Архитектура памяти NT — это система виртуальной памяти, использующая
32—разрядные адреса в плоском (линейном) адресном пространстве. Величаль-
ное адресное пространство процесса (virtual address space) — это набор адре-
сов, которые могут использовать потоки процесса. Во время выполнения дис-
петчер виртуальной памяти при помощи аппаратных средств транслирует, или
отображает (тар) виртуальные адреса в физические адреса, по которым дан-
ные хранятся па самом деле. Посредством контроля над процессом отображе-
ния ОС может гарантировать, что процессы нс будут пересекаться друт с другом
и не повредят ОС
Виртуальное адресное пространство каждого процесса равно четырем
гигабайтам (23- байта), два из которых предназначены для использования про-
граммой, а другие два зарезервированы для ОС. Четыре пп абанта (и даже два) —
это гораздо больше объема физической намято, доступного па обычных маши-
нах. Когда физической памяти не хватает, диспетчер виртуальной памяти пере-
сылает, или “оччсачивает” час ть содержимого памяти на диск. Перемещение дан-
ных на диск освобождает физическую памячъ, и ее теперь можно использовать
Для других целей. При обращении иотока по виртуальному адресу, сосугветству-
Ющему откачанным па диск данным, диспетчер виртуальной памяти снова за-
гружает информацию с диска в память. Более подробно виртуальная память
описана в гл. 6, “Диспетчер виртуальной памяти”.
В Windows NT ОС располагается в верхней части виртуальной памячи, а
Пользовательский код и данные в нижней, как показано па рис. 2-13. Поток
пользовательского режима нс может производить непосредственную запись и
чтение системной памяти.
Часть системной памяти, называемая резидентный пулом (nonpaged pool),
никогда не откачивается па диск и используется для хранения некоторых еххьек-
тов NT и других важных структур данных. Другая часть системной памяти, кото-
FFFFFFFFh
Не откачивается
Система
(2 Гбайт)
Откачивается
Диапазон физических адресов
800000001т
7FFFFFFFh
Резидентный код ОС
Пользовательский код
и данные
(2 Гбайт)
Откачивается
OOOOOOOOh
Рис. 2-13. Адресное пространство NT.
рая может быть перемещена па диск, называется нерезидентным пулам (paged
pool). Всю пользовательскую память можно откачать (подробнее см. гл. 6, “Дис-
петчер виртуальной памяти”).
3.6 Ввод-вывод и файловые системы
Как и в случае с памятью, подсистемы среды обеспечивают такие средства ввода-
вывода, которых ожидают от них приложения. Эти специфичные средства обеспе-
чивают подсистемы среды при помощи обращений к базовым сервисам NT.
В основе ст ютемы ввода—вы вода лежит aci п кронная модель ввода-вывода,
однако подсистемам среды гцждоставляются системные сервисы, позволяющие
им реализовывать как асинхронную, так и синхронную модели. АсинхроннвН
ввод-вывод (asynchronous I/O) позволяет программе запросить выполнение
операции ввода—вывода, после чего продолжать выполнение другой работа
пока устройство не закончит пересылку данных. Система ввода—вывода авто»13
тически уведомляет программу о завершении ввода-вывода, так что программ
может выполнять последующую обработку’. Так как устройства ввода-выво-’1'
обычно работают существенно медленнее процессоров, то программа, вып()1
няющая много операций ввода-вывода, в ряде случаев может повысить <l!t'”
производительность, используя асинхронный ввод-вывод.
Windows NT поддерживает несколько файловых систем, включая ф(Ч‘д°
вую систему FAT (file allocation tabic), высокопрогаводителъную файловую д*
тему (high performance file system. HPFS) и новую файловую систему, под паз*’4
нисм файловая система NT(J\V file system, NTFS). NTFS расширяет возможп*^1
как FAT. так и HPFS, добавляя к ним следующие:
® Средство восстановления файловой системы, позволяющее быстро и1’1
стапанливать данные на диске после системного сбоя.
лете z. Общие сведения о Системе
• Способность с легкостью работать с постелями данных большого
объема — до 2*’* байт, или приблизительно 17 миллиардов гигабайт.
и Средства контроля доступа, в том числе файлы “только для исполнения”
Имена файлов, записанные в стандарте Unicode, что позволяет переме-
щать документы между компьютерами, находящимися в разных стра-
нах, без искажения имен файлов и каталогов (см. разд. 2.3.1).
® Поддержка среды ОС POSIX, включая жесткие связи (hard links), имена,
отличающиеся только регистром букв, и информацию о времени пос-
леднего открытия файла.
Средства для будущего расширения, такие как обработка транзакции
для поддержки отказоустойчивых приложений, задаваемые пользовате-
лем номера версий файла, несколько потоков данных в одном файле,
гибкие возможности задавать имена и атрибуты файлов, а также под-
держка популярных фагот—серверов.
Диспетчер ввода-вывода позволяет драйверам устройств и файловым си-
стемам (которые он также рассматривает как драйверы “устройств”) динамичес-
ки загружаться и выгружаться из системы, в зависимости от потребностей
пользователя. Драйверы являются модульными и могут располагаться слоями един
над другим, что позволяет, например, разным файловым системам использовать
для доступа к файлам один и тот же драйвер диска, как показано на рис. 2—14.
Пользовательский
режим
Режим ядра
Рис. 2-14. Слои драйверов.
ЮВЫ WINDOWS NT
Послойная модель драйверов позволяет также вставлять в иерархию ц(1
выс драйверы. Например, логические драйверы файловых систем или драйверу
отказоустойчивости могут располагаться на средних уровнях иерархии.
Windows NT обеспечивае т доступ к файлам в сетях LAN Manager при
щи драйвера файловой сис темы, называемого редиректором Windows NT. Рсдщ
ректор принимает запросы для удаленных файлов и направляет их серверу
Manager на другой машгп ie.
Другие детали архитектуры
Мы еще не охватили всех важнейших элементов Windows NT. Некоторые темы
будут обсуждаться далее в этой книге, другие же оставлены для будущих книг.
Однако есть две темы, которые нельзя привязать к какому-либо одному компо-
ненту ОС (или к какой-то конкретной главе этой книги), но которые слишком
важны, чтобы их опустить. Первая это поддержка интернационализации ц
Windows NT, которая дает пользователям разных стран возможность рабо тать с
ci «темой на их родном языке. Она также предоставляет разработчикам средства
для написания интернациональных приложений. Вторая тема — структурная
обработка исключений, средство, предоставляемое Microsoft С и поддерживае-
мое ядром NT. Она помогает создавать устойчивые приложения. Windows NT,
написанная по большей часто на Microsoft С, использует структурную обработку
исключений для повышения надежности ОС.
Ни одну из этих тем невозможно адекватно рассмотреть на нескольких
страницах. Тем не менее, два следующих раздела дают некоторое представление
о вопросах, связанных с интернационализацией и структурной обработкой ис-
ключений, а также общее описание их поддержки в Window s NT. Источники до-
полнительной информации Вы можете найти в библиографии в конце книги.
1 Интернационализация
Теперь, с появлением реактивных самолетов и сложного телекоммуникацион-
ного оборудования, мир становится меньше и меньше. Как следствие этого. меж-
дународные рынки начинают играть все более важную роль для компьютер-
ной промышленности. Продажи программ за рубежом составляют большую.
чем когда-либо, долю рынка приложений. Перед Windews NT стоит задача сде' 2.3/
латься истинно многоязычной ОС, дающей солидную основу для разработки 11
применения интернациональных приложений.
Видимая для пользователя часть поддержки интернационализации нахе
дится в 11ансли Управления (Control Panel) Window's NT. как показано на рис. 2- *?
Само Д1галоговое окно выглядит так же, как и в Window's 3.0. Однако, то,
скрыто за пользовательским интерфейсом, сильно изменилось. Поддержка и”
тернационализации в Windows NT значительно более рациональна и обеспс'411
вает модульные средства как для приложений, так и для важных системных ко*1
понентов, таких как подсистема Win32. В следующих версиях пользователе1'111
интерфейс средств интернационализации будет развиваться дальше.
Глава 2. Общие снедения о системе
International
Country [United States Language [English (United Stales) Keyboard Layout |lJS Measurement [English List Separator [ Qate Formal 10/15/96 | Change. j J*1 Г~ок | [^j [ Cancel [ . 1*1 I n«lp 1 __J*1 Currency Format »1 22 । ->
Tuesday. October IS. 1996 rT ime Format Change... 1
Number Formal
6 22 52 PM | Change., j 1.234 22 [thinge... |
-1.234 22
Рис. 2-15. Диалоговое окно установок интернационализации.
з|с sjc sjc *й» -й- -й- * “й* * «й* *й* *й* *й* -3“ -й- "й* -й- -й* -й* * -й* -й- -3* -й* *й* -й- -й- *й* *й* -й* «й* «й* -й- -й- -й- -й- -й- -й- *й* -3- -й- -й- -й- -й* -3-
В Windows NT 4.0 национальная поддержка получила дальнейшее развитие. В Control Panel можно
указать такие параметры, как регион системы, устанавливаемый по умолчанию, регион текущего
пользователя, зарегистрировавшегося локально, а также раскладки клавиатуры.
1-1 Регионы
Рынки с различными национальными и культурными особенностями, называе-
мые регионами (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 (стай'
[лава 2. Общие сведения о системе
дарт ISO 8859-1) и определяющий коды для всех европейских символов, кото-
рых нег в ASCII. В Microsoft Windows используется несколько измененный вари-
ант Latinl, который называется кодовым набором Windows ANSI. Windows ANSI
является однобайтовой схемой кодирования (single—byte coding scheme), так
как для представления каждого символа в нем используется 8 бит. Максималь-
ное число символов, которое можно представить с использованием 8 бит,
равно 256 (2«).
Алфавит (script) — это набор литер, необходимых для записи текста на
некотором языке. Часто один и тот же алфавит используется несколькими
языками: например, кириллица применяется как в русском, так и в украинском.
Windows ANSI и другие однобайтовые схемы могут закодировать количество
символов, достаточное для представления букв любого западного алфавита.
Однако восточные алфавиты, такие как японский или китайский, в которых
используются тысячи разных символов, не удается закодировать при помощи
однобайтовой схемы. В таких случаях используют двухбайтовую схему кодиро-
вания, когда для каждого символа требуется 16 бит, либо многобайтовую, в кото-
рой одни символы представляются 8 битами, а другие 16, 24 или 32 битами. Пос-
ледняя схема требует применения сложных алгоритмов разбора для определе-
ния длины данного символа. Более того, большое число кодовых наборов озна-
чает, что данному коду могут соответствовать совершенно разные символы на
разных компьютерах, в зав! юимости от используемых на этих компьютерах кодо-
вых наборов.
Для решения проблем множественности схем кодирования и для поддер-
жки более широкого набора алфавитов Windows NT использует для представле-
ния данных новый стандарт Unicode. Unicode — это 16—разрядная схема кодиро-
вания символов, в которой можно представить 65536 (2“’) символов. Этого дос-
таточно для всех современных, а также нескольких старых или мертвых языков,
имеющих ограниченное применение (например, санскрита и, мижст быть, еги-
петских иероглифов). Unicode также включает знаки препинания, математичес-
кие символы и набор графических символов, называемых дингбатами5 (dingbats),
после чего еще остается много места для расширений.
В Unicode “суть” символа отделена от информации о шрифте или форма-
тировании, используемой для его отображения. Каждому коду соответствует
один (и только один) символ; для отображения символов Unicode в различных
стилях и формах к ним применяется информация о шрифте. Раскладка алфави-
тов и символов в Unicode показана на рис. 2—16
Хотя подсистема Win32 предоставляет варианты функций API как для
строк ANSI, так и для строк Unicode, последний является “родным” кодовым на-
бором Windows NT. Все строки в системе, включая имена объектов, имена путей,
имена файлов и каталогов, представляются 16—разрядными символами Unicode.
Даже подсистема Win32 преобразует передаваемые ей символы ANSI в символы
Unicode, прежде чем обрабатывать их; перед возвратом управления она, при
необходимости, преобразует строки обратно из Unicode в ANSI.
Я безуспешно пыталась узнать, почему эти символы называются "дингбатами'’. Если кто нибудь зна-
ет отчет, пожалуйста, удовлетворите мех- любопытство, послав для меня информации» в Microsoft Press.
' Рис. 2 16 — это несколько измененная иллюстрация Асмуса Фрейтага (Asmus Freytag), вице-прези
дейта Unicode Consortium по маркетингу.
Применение Unicode позволяет устранить все ограничения на набор сцЧ1
волов, которые могут бычъ представлены в Windows NT. Так как Unicode обссце,
чивает уникальный код для каждого символа любого алфавита, Windows
может гарантировать, что преобразование символов как на выходе, так и
входе в систему будет всегда правильным.
2 Структурная обработка исключений
Вторая особая архитектура, поддерживаемая и используемая Windows NT, назы-
вается структурной обработкой исключений. Исключения (exceptions') — ЭТо
синхронные ошибки или нетипичные события, вызывающие исполнение кода
вне обычного потока управления. В отличие от прерываний, которые генериру-
ются внешним источником, исключения возникают при исполнении програм-
мой некоторого кода и могут быть воспроизведены.
Например, когда программа вызывает функцию С mallocQ, типичным ре.
зультатом будет выделение памяти и возвращение указателя на нее. Исключи-
тельная ситуация возникает тогда, когда из-за некоторой проблемы, например,
недостатка свободной памяти, не удается выделить новый блок. При этом функ-
ция возвращает указатель NULL.
Знаки пунктуации,
математические и технические
символы, дингбаты (графические символы)
греческий, и корейские
армянский алфавиты
алфавиты (бопомофо,
и кириллица хирагана,
катакана,
хангул...)
Для использования в будущем
Для совместимости со стандартными, отличными от Unicode наборами символов
Рис. 2-16. Раскладка Unicode.
iaobq z.ощие сведения о системе
Возврат особого значения, указывающего на исключение — это обычная,
но примитивная форма обработки исключений, и она имеет ряд недостатков.
Во-первых, программист обязан скрупулезно соблюдать ритуал проверки воз-
вращаемого значения и либо реагировать на ошибки, либо передавать их на
более высокий уровень программы. Если на одном из уровней проверка не про-
водится, то ошибки могут повлиять на нс имеющие отношения к месту их воз-
никновения части программы. Во-вторых, текст программы загромождается
операторами If._Then...Else, обрабатывающими нетипичные случаи. В-третьих,
информация о причине возникновения проблем нс всегда легко доступна коду,
который должен обработать ошибку.
Исключения могут обнаруживаться как программно, так и аппаратно. На-
пример, аппаратура обнаруживает исключения “деление на 0”, тогда как про-
граммное обеспечение определяет нарушения защиты памяти. Структурная об-
работка исключений — это метод, применяемый Windows NT для обработки как
программных, так гi аппаратных гюключений, с i юпользоваш icm структур управ-
ления (отсюда и название) некоторого языка программирования. Структурная
обработка исключений позволяет любому блоку’ кода определить, от исключе-
ний каких типов он хочет защищаться, и зарегистрировать специальный учас-
ток кода — обработчик исключений (exception manager), который исполняется
при возникновении исключений заданных типов в этом блоке.
Приводимый ниже код представляет собой пример процедуры на
Microsoft С, в которую входит обработчик исключений. Функция является моди-
фицированным вариантом стандартной библиотечной функции strlcn(), воз-
вращающей длину строки, которая заканчивается нулевым символом.
Обычная функция strlcn() быстро просматривает память по одному симво-
лу, до тех пор пока нс найдет символ NULL. Но если строка нс заканчивается
нулем или указатель на строку неверен, то strlcn() может внезапно завершиться
с исключением “нарушение защиты памяти”.
Приведенная здесь модифицированная версия перехватывает исключение
и возвращае т осмысленное значение (нс обязательно верное, просто осмыслен-
ное) вместо аварийного завершения программы Новое ключевое слово try слу-
жит отметкой начала блока кода, который может вызвать нарушение защиты.
Если исключение возникает внутри этого блока, то управление передается на
ключевое слово except, за которым в скобках следует фильтр исключений. Фильтр
исключений даст возможность задать обработку только для некоторых типов
исключений. Если значение фильтра равно EXCEPTION EXECUTE HANDLER, то
исполняется обработчик исключения, в данном случае оператор return (count).
Фильтры исключений — это достаточно мощное средство, так как они могут
обращаться к локальным данным и иметь любую сложность. Применение филь-
тров позволяет исполнять обработчик только при точном соблюдении задан-
ных условий. Передача управления обработчику исключений называется воз-
буждением исключения (raising an exception). Обратите внимание, что код обра-
ботки ошибок удален с основного пути выполнения программы.
WINDOWS NT
О /*safelen: возвращает осмысленную длину строки s, Q
даже если получает неверный указатель на строку */
О О
int safelen(char *s)
{
О int count = О; О
О try { О
while (*s++ != *\0’)
_ /* возможно нарушение защиты памяти */
count++;
return (count); q
except (GetExceptionCode() = ACCESS VIOLATION ?
О EXCEPTION_EXECUTE_HANDLER: О
EXCEPTIONCONTINUESEARCH)
О < о
/* неверный указатель или строка не заканчивается нулем */
О return (count); О
}
О } О
Каждый блок кода может иметь собственный обработчик исключений, и
обработчики могут быть вложены друг в друга. При возникновении исключения
фильтр исключений может проверить его тип и по результатам проверки ука-
зать ОС: выполнить обработчик исключений, продолжить выполнение програм-
мы, завершит ь работу программы или продолжить поиск обработчика в охваты-
вающем блоке кода.
Исключения ОС — не единственный тип исключений, которые может об-
рабатывать приложение. Приложения сами могут генерировать исключения
при помощи функции Win32 API RaiseException(), вызывая тем самым передач)
управления соответствующему обработчику исключений. Для поддержки этой
операции ОС регистрирует обработчики исключений и просматривает их в
надлежащем порядке в случае возбуждения исключения. Если ни один из обра'
ботчиков не взялся за обработку проблемы, то ОС завершает программу, вызвав-
шую ошибку. Средство обработки исключений Windows NT не зависит от нс
пользуемого языка программирования; один и тот же механизм использует^
для всех языков. Каждый язык определяет, каким образом в нем раскрываете’1
этот механизм.
Другой тип обработчика исключений, известный как обработчик завсР
шения (termination handler), позволяет приложению гарантировать выполнен’^
некоторого блока кода, даже если защищенный блок завершается ненормалы10'
Обработчики завершения часто содержат код, освобождающий ресурсы, чтобй
в случае ненормального завершения процедуры выделенные ею ресурсы оЫ-’^
возвращены системе. Следующий фрагмент кода иллюстрирует назначение о°
работчика завершения:
Глава 2. Общие сведения о системе
/* выделить и инициализировать
глобальный объект — критическую секцию */
О
о
о
о
о
LPSTR Buffer;
Buffer = NULL;
/* войти в критическую секцию и выделить буфер */
try {
EnterCriticalSectionf&CriticalSection);
Buffer = LocalAlloc(LMEM_FIXED, 10);
if(lBuffer) {
return;
}
strcpy( Buffer, “Hello");
}
finally {
/‘чтобы ни произошло, выйти из критической секции и
освободить буфер */
if(Buffer != NULL)
LocalFreef Buff е г);
LeaveCriticalSection(&CriticalSection);
}
О
Критическая секция — это синхронизационный объект Win32, который
гарантирует, что данный блок кода будет исполняться одновременно не более
чем одним потоком. В нашем примере поток получает доступ к критической
секции, выделяет буфер, после чего модифицирует его содержимое. Если слу-
чится что-то не то (например, произойдет необработанное исключение) и про-
цедура завершится в тот момент, когда поток находится в критической секции,
то остальные потоки, ожидающие доступ к этому ресурсу, будут заблокированы
навсегда. Более того, буфер, выделенный пот оком, будет потерян, так как ОС не
сможет его освободить сама. (Разработчики часто называют такого рода ошиб-
ки утечками памяти. Если их происходит слишком много, то память постепенно
“утекает”.) Обработчик завершения гарантирует, что поток освободит объект-
критическую секцию и буфер. Обработчики завершения исполняются всегда,
когда поток управления выходит из тела блока try...finally, независимо от способа,
которым происходит этот выход.
Обработчики исключений и завершений могут использоваться для дости-
жения устойчивой работы приложения как по отдельности, так и в комбинации.
Windows NT используег оба типа обработчиков для обеспечения надежной ра-
боты на всех уровнях системы.
Заключение
Теперь у Вас есть представление о некоторых основных особенностях Windows
NT. Это база ОС с симметричной мультипроцессорной обработкой, поддержи-
вающая несколько сред ОС. Windows NT обладает графическим интерфейсом
пользователя Windows и может выполнять программы Win32, 16-разрядn<)f,
Windows, MS-DOS, POSIX и OS/2. В ней использованы самые современные прин-
ципы построения ОС, такие как виртуальная память, вытесняющая многозадач-
ность, структурированная обработка прерываний и объекты ОС. Система явля-
ется защищенной, мощной, надежной и гибкой. Windows N1 обладает рядом
возможностей, которые ранее были только у ОС больших ЭВМ и миникомпью-
теров. Другими словами, W indows NT — это скоростной локомотив, втиснутый
в коробку от скейтборда: глядя на нее, легко представить себе будущее настоль-
ных ЭВМ. Но Вы можете составить свое собственное суждст п ie о ней. Следующие
главы этой книги подробно раскрывают разные стороны Windows NT, начиная
с объектов — ее способа представления, управления и защиты своих ресурсов.
ГЛАВА 3
ДИСПЕТЧЕР ОБЪЕКТОВ
И КОНТРОЛЬ ДОСТУПА
(Объект!ю—ориентированные языки, пользовательские интерфейсы и ОС были
популярной темой среди компьютерных энтузиастов во второй половине 80-х
годов. Объекты вдруг стали рекламироваться в качестве панацеи от всех про-
блем в программировании. Однако объекты — это не есть что-то повое. Впервые
они появились в конце о0—х в языках программирования, таких как Симула, ко-
торые разрабатывались в основном для создания программ моделирования.
Подобные программы моделируют поведение объектов реального мира. Таким
образом, объектно-ориентированное программирование, которое обеспечива-
ет способ предс тавления и манипулирования как физическими, так и абстракт-
ными объектами, является естественным подходом в данной области.
Операционные системы также работают с объектами. Их объектами явля-
ются аппаратные ресурсы, например ус тройства ввода-вывода пли память, либо
программные ресурсы, такие как файлы, процессы и семафоры. Большинство
ОС ставят во главу утла различия между ресурсами и работают с каждым типом
ресурсов по-своему. В то же время представление ресурсов в виде объектов ис-
пользует сходство между ними. При этом все управление ресурсами сосредота-
чивается в одном месте, и обеспечивается общая модель их использования.
Наше путешествие внутри Windows NT начинается с исполнительной сис-
темы NT, а конкретно, с ее объектов. Трудно начать откуда-либо еще, так как
процессы, потоки, файлы и даже подсистема Win32 (процесс) — все это объек-
ты. Следовательно, изучение системы объектов NT поможет нам в понимании
других, самых разных частей ОС.
В первом разделе этой главы описываются существующие в Windows NT
типы объектов и способы их использования. Предмет второго раздела — струк-
тура объектов и то. как диспетчер объектов управляет ими. Третий раздел посвя-
щен главной задаче системы защиты Windows NT защите объектов.
1 Объекты исполнительной системы NT
Что такое объект? В исполнительной системе NT объект — это отдельный обра-
зец статически определенного типа объектов, существующий во время выполне-
ния. Тип объектов (object type), иногда называемый классам объектов (object
ОВЫ WINDOWS NT
class), включает определенный системой тип данных, сервисы, работающие ,•
образцами этого типа, и набор атрибутов объекта. При написании Win32-при,
ложения Вы столкнетесь с объектами, представляющими, к примеру, процссс
поток, файл, собы тие. В основе этих объектов лежат низкоуровневые объекты
которые создаются и управляются исполнительной системой NT. В Window s \у
процесс — это пример обьекта тина “процесс", файл — пример объекта тпц;1
“файл” и т. д.
Атрибут объекта (object attribute) — это поле данных внутри объекта
частично определяющее его состояние1.Объект типа “стек”, например, имел бы
в качестве одного из самых важных атрибутов указатель стека. Объектные сер-
висы (object services) — способы манипулирования обьектами — обычно считы-
вают или изменяют атрибуты объекта. Например, сервис “push” (поместить в
стек) для объекта-стека изменял бы значение указателя стека.
Наиболее фундаментальное различие между объектом и простой стру-кту.
рои данных состоит в том, что внутренняя структура обьекта скрыта от наблю-
дателя. Для извлечения данных из объекта или помещения в него информации
необходимо вызывать объектные сервисы. Вы не можете непосредственно счи-
тывать пли изменять внутренние данные объекта. Таким образом, внутренняя
реализация объекта отделяется от кода, который лишь использует данный объект;
эта техника позволяет в дальнейшем легко изменять реализацию объекта.
Команда проектировщиков исполнительной системы NT приняла реше-
ние использовать объекты для представления системных ресурсов, потому что
объекты дают способ централизованного выполнения трех важных (и часто ру-
тинных) задач OG
- Присвоение системным ресурсам читабельных имен
J Совместное использование ресурсов и данных разными процессами
* Защита ресурсов от несанкционированного доступа.
Не все структуры данных в исполнительной системе NT являются объек-
тами. В объекты помещены только те данные, которые должны быть совместно
используемыми, защищенными, именованными пли видимыми (при помоют
системных сервисов) программам пользовательского режима. Структуры,
используемые, например, только одним компонентом исполнительной систе-
мы для реализации внутренних функции, нс являются обьектами.
Несмотря на то. что объекты широко используются для представления
совместно используемых системных ресурсов, Window's NT не является объект-
но— ориентирован ной системой в строгом смысле слова. Большая часть код-’
ОС написана на С, чтобы обеспечить переносимость и из-за того, что среД'
ства разработки широко доступны. С нс поддерживает непосредствен”0
объектно-ориентированные конструкции, такие как динамическое опред0'
ление типа данных, полиморфные функции или наследование классов. Так”'1
образом, реализация объектов в Windows NT, выполненная на С, заимствуй
идеи, по нс зависит от средств, предоставляемых конкретными объекты0'
ориентированными языками.
1 При создании объекта при помощи API Vtin52 либо базовых объектных сервисов вызываю11*'1’'
программа передаст параметр под названием ObjectAttributes (Атрибуты Объекта). по его не
дует смешивать с более общим значением данною термина, которое используется в этой книге.
Глава 3. Диспетчер объектов и контроль доступа
Диспетчер объектов (object manager) — это компонент исполнительной
системы NT. отвечающий за создание, удаление, защи ту и учет объектов NT Дис-
петчер объектов централизует операции управления ресурсами, которые иначе
были бы разбросаны по всей ОС. Лу Пераццоли (Lou Pcrazzoli), технический
управляющий и руководитель проекта разработки Windows NT, и Стив Вуд (Steve
Wood), программист ОС Microsoft с 9-летним стажем, спроектировали диспет-
чер объектов и определили следующие цели его реализации:
• Обеспечи л, общий, унифицированный механизм использования сис-
темных ресурсов.
• Сосредоточить защиту объектов в одном месте ОС, чтобы удовлетво-
рить требованиям правительства США по защите класса С2.
• Обеспечить схему именования объектов, которую легко было бы ис-
пользовать для существующих объектов, таких как устройства, файлы
и каталоги файловой системы, а также для других независимых набо-
ров объектов.
Ввести способ назначения цены использования объектов процессами,
так чтобы системный администратор мог устанавливать ограничения
на использование системных ресурсов.
в Задать унифицированные правила удержания объектов (т.е. сохране-
ния обьекта доступным до тех пор, пока все процессы не закончили
пользоваться им).
Ж Поддерживать требования разнообразных сред ОС. такие как способ-
ность процесса наследовать ресурсы родительского процесса (необхо-
дима для Windows и POSIX) и возможност ь использовать имена файлов,
различающиеся только регистром букв (необходима для POSIX).
В следующих подразделах изложены основные сведения об объектах ис-
полнительной системы NT, включая описание их структуры и способов исполь-
зования в ОС.
3.1.1 Использование объектов
Исполнительная система NT реализует два типа объектов: объекты исполни-
тельной системы (executive object) и объекты ядра (kernel object). Объекты
исполнительной системы представляются различными компонентами исполни-
тельной системы NT. Они доступны программам пользовательского режима (за-
щищенным подсистемам) посредством базовых сервисов NT и могут создавать-
ся и использоваться как подсистемами, так и исполнительной системой NT.
Объекты ядра — это более примитивный набор объектов, реализованный
ядром NT. Эти объекты невидимы коду' пользовательского режима, а создаются и
используются только внутри исполнительной системы NT Объекты ядра обеспе-
чивают фундаментальные функции, такие как возможность изменять планирова-
ние в системе, которые могут выполняться только самым низким уровнем (Х: —
ядром. Многие объекты исполнительной системы содержат (инкапсулируют)
один или t ксколько объектов ядра. 11а данный момент мы будем иметь дело толь-
ко с типами объектов, видимыми в режиме пользователя, которые перечислены в
табл. 3-1 вместе с определяющими их компонентами исполнительной системы.
ВЫ WINDOWS NT
Таблица 3-1. Объекты исполнительной системы
Тип объекта Реолизующий компонент Что представляет собой
Процесс Диспетчер процессов Один вызов программы, включая адресное пространство и ресурсы, необходимые для ее исполнения
I 1оток Диспетчер процессов Исполняемая сущность внутри пре >цссса
Секция Диспетчер памяти Область совместно используемой памяти
Файл Диспетчер ввода вывода Образец открытого файла или устройства ввода вывода
Порт Механизм LPC Место назначения сообщений, пересылаемых между процессами
Маркер дос-ryi ia Система защиты Закодированный идентификатор, содержа щий информацию о нравах доступа за|х*- i-HCTpi(ровавшсгося в ci ютемс пользовате. ш
Событие Вспомогательные сервисы исполни тельной системы Объявление о том, что произошло системное событие
Пара событий То же Уведомление о том, что специальный по- ток клиента скопировал сообщение серве- ру Win32 или наоборот (используется только подсистемой Win32)
Мутант2 То же Механизм обеспечения взаимного исклю- чения для сред Win32 и OS/2
Семафор То же Счетчик, регулирующий число потоков, которые могут использовать некоторый ресурс
Таймер* То же Счетчик времени
Каталог объектов Д1 ютстчер объектов Хранилище в памяти для имен объектов
Сим воличсс кая связь То же Механизм косвенной ссылки на имя объекта
Предашь Ядро Механизм, позволяющий оценить распреде- ление времени исполнения внутри блока ко- да (для оптимизации пропзводителыкхти)
Параметр Диспетчер Индексный ключ для ссылки па записи в
реестра конфигурации базе данных конфигурации Windows NI
- Имя мутант имеет интересную историю. В начале разработки Windows NT Дэйв Катлер с<>
здал объект- ядра — мьютекс, реализующий низкоуровневое взаимное исключение. Позднее <т
обнаружил. что OS/2 требует- для взаимного исключения версии семафора, имеющей дополни
тельную семантику, которую Дэйв посчитал 1 повреждающей рассудок* и которая оказалась н<
совместимой с первоначальным объектом (конкретно, поток moi покинуть объект и остлвнтт»
его в недоступном состоянии). Тогда Дэйв создал версию мьютекса для OS/2 и дал ей имя иг
таит. Позднее он изменил объект—мутант, чтобы устранить зависимость от OS/2 и дать возмож
ность использовать этот объект системе Win32. В АН Win32 модифицированный объект ндзывЛ
сися мьютекс, но в базовых сервисах сохранилось имя мутант.
* В Windows NT версии 3.51 Sen ice Рас k 3 добавлен новый объект — ожидающий таймер. Подроб
нее см. сноску в следующей главе.
Глава 3. Диспетчер объектов и контроль доступа
Каждая подсистема Windows NT создает для своих приложении разные
образы ОС. Объекты исполнительной системы и объектные сервисы — это при-
митивы, используемые подсистемами среды для создания их собственных вер-
сии объектов и других ресурсов. Набор объектов, которые подсистема среды
предоставляет своим приложениям, может быть шире или уже предоставляемо-
го исполнит ельной системой NT. Некоторые подсистемы, такие как POSIX. вооб-
ще нс поддерживают объекты как объекты. Подсистема POSIX используе т объек-
ты и сервисы исполнительной системы как основу, чтобы представить своим
приложениям процессы, каналы и другие ресурсы своим собственным спосо-
бом. Другие подсистемы, например Win32, используют объекты исполнитель-
ной системы NT для создания собственных версий объектов. Подсистема Win32
предоставляет стоим приложениям мьютексы и семафоры — и тс и другие пспос
редсгвенио основаны на объектах исполнительной системы NT. Кроме того, под-
система Win32 реализует именованные каналы и почтовые ящики — ресурсы, в
основе которых лежат файловые объекты исполнительной системы NT.
Данная глава посвящена объектам исполнительной системы, т.с. тем. ко-
торые реализуются исполнительной системой NT. Их не следует путать с
объектами, доступ к которым предоставляется прикладным программам по-
средством API Win32, POSIX или OS/2.
3.1.1.1 Файловая модель
Для прикладного программиста Windows NT выглядит или как Windows, или
как MS-DOS, или как POSIX, пли как OS/2. Только системным программистам,
которые пишут подсистему среды, файловую систему, базовый драйвер уст-
ройства или другую специализированную программу, приходится изучать
объекты исполнительной системы и непосредственно их использовать.
Обычно объекты исполнительной системы создаются либо защищен-
ной подсистемой, в качестве непосредственной реакции па некоторое дей-
ствие пользователя, либо различными компонентами ОС в процессе их нор-
мальной работы. Например, для того чтобы создать файл, приложение Win32
вызывает функцию API Win32 CreateFilef). В свою очередь, подсистема Win32
вызывает базовый сервис NT, создающий файловый объект исполнительной
системы. Когда затем приложение читает файл гиги пишет в пего, подсистема
Win32 и исполнительная система NT используют файловый объект для обра-
щения к файлу.
Работа с файлами — это нетипичный случай для объектной системы NT.
так как файлы являются постоянными ресурсами и расположены гге в памяти.
Одггако огги важны, так как модель работы с файлами, используемая большин-
ством языков программирования, удобна для создания и использования объек-
тов NT. Ниже приведены интересующие ггас характеристики файловой модели:
В большинстве языков программирования необходимо открыть файл,
прежде чем можно будет выполнять его чтение или запись. Операция
открытия может либо открыть существующий файл, либо создать но-
вый, с указанным Вами имеггем. Имя файла может включать каталог
(или их иерархию), в котором этот файл хранится.
При открытии файла задастся тип операций, которые с ним будут про-
изводиться: например, чтение, запись или дописывание к концу файла.
>ВЫ WINDOWS NT
* - Файловая система открывает файл и возвращает его описатель, кот<>.
рый используется в последующих операциях для ссылки на этот файд.
Когда работа с файлом закопчена. Вы закрываете описатель файла
* Две программы совместно используют некоторый файл, если обе оцц
открывают его описатель в одно и то же время. Некоторые файловые
системы также позволяют приложениям создавать временные файлы,
которые автоматически удаляются файловой системой, когда закрыва-
ются все их описатели.
С некоторыми отклонениями, объектная модель Windows NT имитирует
файловую модель. Основные отличия состоят в том, что описатели называются
описателями объектов (object handles) и объекты хранятся в памяти, а нс па
физическом устройстве. В следующем разделе объектная модель NT рассматри-
вается более подробно.
Объектная модель
Как и в большинстве ОС, единицей работы в NT является процесс. Каждому гцэц-
цессу выделяется набор ресурсов, позволяющих ему выполнять свою работу по-
ток, чтобы можно было выполнять программы, п адресное пространство для хра-
нения кода и данных. В процессе работы поток может запросить для своего про-
цесса дополнительные ресурсы путем создания объектов или открытия описате-
лей существующих объектов. Описатели объекта уникальны для процесса и ука-
зывают на доступ процесса к системным ресурсам. Они могут быть использовш 1ы
для вызова базовых сервисов объекта, осуществляющих действия с ресурсами.
Подсистема Win32 — это процесс NT, который выступает как сервер для
приложений Win32. Когда приложение вызывает функцию API Win32, которая
прямо или косвенно создает объект, подсистема Win32 обращается к некоему
объектному сервису NT. Здесь в дело вступает диспетчер объектов NT, который
выполняет следующие функции:
Выделяет память для объекта.
к Присоединяет к объекту дескриптор защиты (security' descriptor), кото-
рый определяет, кому и как разрешено использовать объект.
Создает I г поддерживает структуру каталога объектов, где хранятся име-
на объектов.
* Создает описатель объекта и возвращает его вызывающей программе.
Все процессы пользовательского режима, включая подсистемы среды-
должны получить описатель объекта, прежде чем их потоки смогут использо-
вать этот объект. Идея применения описателей для манипулирования систем'
ными ресурсами отнюдь не нова. Библиотеки периода выполнения С и Н;,с'
каля (а также других языков), например, возвращают описатели при открЫ'
тип файлов. Аналогично, приложения Win32 используют различные типы
описателей для управления окнами, курсором мыши и значками. В обоих слу'
чаях описатели служат косвенными указателями на системные ресурсы; з'г:*
косвенность предотвращает непосредственный доступ приложений к спс'
темным структурам данных.
Для исполнительной системы NI описатели объектов создают дополи11'
тельные преимущества. Во-первых, нет никаких различий между описателем
тливо о. auci ютчор объектов и контроль доступе
файла, описателем события и описателем процесса (за исключением того, на
что они ссылаются). Нс нужно запоминать десять разных механизмов для ра-
боты с десятью разными типами объектов. Во-вторых, диспетчеру объектов
принадлежит исключительное право создания описателей и поиска объекта по
его описателю. Эго означает, что любое действие в пользовательском режиме,
затрагивающее некоторый объект, может контролироваться диспетчером
объектов. Благодаря этому эффекту шлюза диспет чер объектов отвечает трем
важным целям проект'.! windows NT:
Он защищает объекты. Всякий раз. когда поток использует описатель,
диспетчер объекта проверяет наличие у потока прав использовать
объект так. как он это пытается сделать.
Он контролирует, кто использует объект, и поэтому' может удалить вре-
менные объекты, которые более нс нужны. Диспетчер объектов не уда-
лит объект, пока у какого-либо процесса имеется описатель этого
объекта (или пока у системы есть указатель на пего).
Он контролирует использование ресурсов. Всякий раз, когда поток от-
крывает описатель объекта, диспетчер объектов списывает с процесса
этого потока объем физической памяти, используемой объектом. Объем
использования ресурсов потоками процесса не может превышать огра-
ничений памяти — квот (quotas), назначенных системным администра-
тором пользователю, который представлен данным процессом.
Первая задача, защита объектов, и составляет суть системы защиты
Windows NT. Ее реализация многое заимствует из файловой модели и до некото-
рой степени видима программам, использующим API Win32. Ниже дается кра т-
кое введение в тему' защиты объектов исполнительной системы NT, к которой
мы еще обратимся далее в этой главе.
Вернемся к аналогии с файлами: при открытии файла необходимо указать,
собираетесь ли Вы использовать его для чтения или для записи. Если Вы попы-
таетесь записать в файл, который открыт только для чтения, то получите ошиб-
ку. Аналогично, в исполнительной системе NT, когда процесс создаст объект пли
открывает описатель существующего объекта, он должен задать набор запраши-
ваемых прав доступа (desired access rights) — т.е. указать, что он намерен делать
с объектом. Можно запросить либо набор стандартных прав доступа (таких как
чтение, запись или исполнение), применимых к объектам всех типов, либо спе-
цифических прав доступа, состав которых зависит от типа объекта. Например,
процесс может запросить доступ для удаления файлового объекта или дописы-
вания к его концу. Аналогично, он можег запросить возможность приостанавли-
вать или завершать объект—поток.
Когда процесс открывает описатель объекта, диспетчер об ъектов вызыва-
ет справочный монитор защиты (security reference monitor) — часть системы
защиты, работающую в режиме ядра — и посылает ей набор запрашиваемых
процессом прав доступа. Справочный монитор защиты проверяет, разрешает
ли дескриптор защиты объекта (security descriptor) доступ, запрашиваемый
процессом'. Если да, то справочный монитор защиты возвращает набор нрав
' Подсистема Win32 позволяет прикладном) процессу назначать объектам дескрипторы защиты,
по не требует этого. Если дескриптор защиты не назначен приложением, то подсистема Win32 де-
лает это за него.
доступа, предостстченпых процессу (granted access rights), и диспетчер объек-
тов сохраняет tix в создаваемом описателе обьекта1
После этого всякий раз, когда потоки процесса используют описатель, дп<
петчер объектов быстро проверяет, соответствует ли хранящийся в описателе
набор представленных прав доступа т ипу использования. который подразумсь.:
сгся об'ьектным сервисом, вызванным потоком. Например, если процесс заправь ।
вал доступ по чтению к объекту—секции, а затем вызвал сервис дчя записи в
секцию, то данный вызов завершится с ошибкой. Способ, которым система защп
ты определяет, кто к каким объектам имеет доступ, рассматривается в разд. > ;
Вторая и третья задача, решаемые с использованием описателен объек
тов, — удержание объектов и учет ресурсов — описаны в разд. 5-2- I » 3-2.2 2
Структура объектов
Каждый объект NT относится к некоторому топу объектов. Тин объекта опре-
деляет, какие данные содержит объект, а также базовые системные серии», ы.
которые могут к нему применяться. Для универсальности обработки разных
объектов диспетчеру объектов необходимо, чтобы каждый объект содержал в
заданном месте несколько полей со стандартной информацией. При наличии
этих данных диспетчеру объектов нс требуется знать, что еще содержится в
объекте. Для отделения стандартных данных объекта от специфичных каждый
объект разделен на две части — заголовок и тело. Диспетчер объектов работ ает
с заголовком, а другие компоненты исполнительной системы — с телами обт>ск-
тов создаваемых ими типов.
Диспетчер объектов использует данные заголовка объекта для обработки
объектов способом, нс зависящим от их типа. Па рис. .5—1 показаны данные,
или атрибуты, содержащиеся в заголовке объекта. Табл. ,5—2 кратко описывает
эти атрибуты.
Заголовок
обьекта
Рис. 3-1. Содержимое заголовка объекта.
’ Это упрощенное представление <>б истинном механизме сохранения, который более подробно
описан далее в .-лч>й главе.
Таблица 3-2. Стандарт! <ые атрибуты заголовка объекта
Атрибут Назначение
Имя объекта Делле объект видимым другим процессам для совместного использования
Каталог объектов Обеспечивает иерархическую структуру и которой хранятся имена объектов
Дсскриптг >р за । ш пы Определяет, кто и каким образом может использовать данный объект
Расход киоты Задает квоту па использование ресурсов, которая списывайся с процесса, когда тот открывает описатель данного объекта
Счетчик открытых описателей Подсчитывает количество открытых описателен данного объекта
база данных откры- тых описателей Содержит список процессов, открывших описатели данного объекта
BpCMCI 111ЫЙ /пос- тоянный статус Указывает, можно ли уничтожить имя и освободить память объекта, если он более не используется
Режим: пользова- тельский /ядра Определяет доступность объекта в пользовательском режиме
Указатель на типовой объект Ссылается на типовой объект, который содержит атрибуты, общие для набора однотипных объектов
Диспетчер объектов предоставляет небольшой набор сервисов общего
назначения, которые работают с атрибутами, хранящимися в заголовке объек та,
и используются с объектами любых типов (хотя для определенных объектов
некоторые универсальные сервисы пс имеют смысла). Эти универсальные сер-
висы, часть которых подсистема Win32 делает доступными для приложений
Win32, перечислены в табл. .3—3.
Таблица 3-3. Универсальные объектные сервисы
Сервис Назначение
Закрыть Закрывает описатель объекта
Дублировать Обеспечивает совместное использование объекта путем дуб пирования его описателя и передачи копии друтому процессу
Опросить объект Опросить защиту Установить защиту Получает информацию о стандартных атрибутах объекта Получает1 дескриптор защиты объекта Изменяет параметры защиты обьекта
Ждать одного объекта Синхронизирует исполнение потока с одним объектом
Ждать несколько объектов Синхронизирует исполнение потока с несколькими объектами
Помимо заголовка, каждый объект имеет тело, формат и содержимое ко-
торого определяются типом обккга; тела всех объектов одного типа имеют
одинаковый формат. Определяя тип объектов и предоставляя сервисы для
него, компонент исполнительной системы может управлять доступом к дан
ным в телах всех объектов данного типа.
Любой компонент исполнительной системы может задавать тип объек-
тов, и большинство из них делают это. Задание типа объекта состоит в том.
чтобы определить данные, которые будут храниться в теле каждого объекта
этого типа, сообщить размер тела диспетчеру обк-ктов, чтобы он мог выде-
лить нужный объем памяти при создании объекта, и предоставить сервисы для
нового типа объектов. Например, диспетчер процессов определяет тело объек-
тов-процессов и обеспечивает сервисы для работы с хранящимися в нем дан-
ными. Аналогично, диспетчер объектов определяет формат тела п сервисы д.Чя
файлового объекта. Содержимое тел различных объектов, а также определяй),
щих их компонентов исполнительной системы NT описывается ниже.
Типы объектов
В заголовке объекта хранятся данные, формат которых одинаков для всех
объектов, но значения могут быть разными. Например, у каждого объекта есть
уникальное имя и может быть уникальный дескриптор защиты. Однако, ест ь и
некоторые данные, которые постоянны для всех объектов данного типа. Напри-
мер, при открытии описателя объекта данного типа можно выбирать права до-
ступа из некоторого набора прав, специфичных для этого типа. Исполнительная
система NT поддерживает (помимо других) права доступа “завершить” и “приос-
тановить” для объектов-потоков и права доступа “чтение”, “запись”, “дописыва-
ние к концу” и “удаление” для файловых объектов. Другим примером типозависи-
мого атрибута является синхронизация, или, коротко говоря, способность по тока
ожидать установления объектов некоторых типов в состояние “свободен”.
В целях экономии памяти и сокращения расходов на управление объекта-
ми диспетчер объектов задает эти статические, типозависимые атрибуты один
раз при создании нового типа объектов. Для хранения этих данных он исполь-
зует специальный объект, называемый типовым объектом (type object). Помимо
этого, типовой объект связывает друг с другом все объекты одного типа, как
показано на рис. 3—2, что позволяет диспетчеру объектов при необходимости
перебрать их все.
Пользовательский режим не имеет доступа к типовым объектам, так как
диспетчер объектов нс предоставляет никаких сервисов для них. Однако неко-
Рис. 3-2. Объекты-процессы и типовой объект процесс".
торыс определяемые ими атрибуты видимы посредством базовых сервисов и
функций API Win32. Атрибуты, хранящиеся в телах типовых объектов, приведе-
ны в табл. 3—1-
Тоблица 3-4. Атрибуты типового объекта
Атрибут Назначение
Имя типа объекта Название объектов данного типа (“процесс”, “событие”, “порт" и т. д.)
Типы доступа Типы доступа, которые могут быть запрошены потоком при открытии описателя объекта данного типа (“чтение", “запись”, “завершить”, “приостановите” и т. д.)
Возможности Clllixpoi 111331 tun Резидентами/! iepc- зндептный Методы Может ли поток ожидать у объектов данного типа Могут ли объекты данного типа выгружаться из памяти Одна или несколько процедур, вызываемых диспет чером объекта автоматически в некоторых точках времени жиз- ни объекта
Синхронизация (synchronization), один из атрибутов, видимых приложени-
ям Win32, указывает на то, что поток может синхронизировать свое выполне-
ние, ожидая, пока нс изменится состояние объекта. Поток синхронизируется со
следующими объектами исполнительной системы: процесс, поток, файл, собы-
тие, пара событии, семафор, мутант и таймер. Объекты секция, порт, маркер
доступа, каталог объектов, символическая связь, профиль и параметр реестра нс
поддерж! шают синхро! 1изаг (Ию.
Последний атрибут в списке методы — состоит из набора внутренних
процедур, аналогичных конструкторам и деструкторам C++, т.е. процедурам,
которые автоматически вызываются при создании и разрушении объекта. Дис-
петчер объектов развивает эту идею, вызывая методы объектов и в других ситу-
ациях, таких как открытие и закрытие описателя объекта или попытка измене-
ния параметров защиты объекта. Некоторые типы объектов определяют методы,
а некоторые нет, в зависимости от назначения типа. Методы, иногда еще назы-
ваемые виртуальными методами (virtual methods), описаны в разд. .3.2.3.
Итак, объекты исполнительной системы NT состоят пз двух частей: заголов-
ка объекта, управляемого диспетчером объектов, и тела объекта, которое управля-
ется компонентом ОС, создавшим данный тип. Одним из атрибутов заголовка
объекта является указатель на типовой объект — структуру, определяющую стати-
ческие атрибуты объектов данного типа. Новый тип объектов может быте опреде-
лен любым компонентом исполнительной ст гстсмы NT, и каждый компона гг пре-
доставляет сервисы для определенных им типов объектов.
3.2 Управление объектами
Как указывалось выше, диспетчер объектов предоставляет набор универсалы пах
сервисов, приме! (и.мых к об ъектам любого типа. Кроме того, другие компоненты
исполнительной сис темы NT обеспечивают тииозависимые сервисы для созда-
ваемых ими типов об'ьек'юв. Эти сервисы вызывают диспетчер объектов посред-
ством внутренних интерфейсов. Следовательно. все сервисы, которые работают
с объектами, должны на том или ином уровне пройти через диспетчер объек
го в. Это позволяет последнему централизовать управление объектами и вы
поднять все соответствующие задачи (или явным образом передавать управле
ние вторичному диспетчеру объектов, если необходимо).
В данном разделе рассмотрены основные функции диспетчера объектов
Поиску объектов и выдаче их описателей посвящены первые два подраздела. В
третьем подразделе более подробно рассматриваются методы объектов. Оппсы
ваемые объекты и сервисы доступны подсистемам пользовательского режим,,
если не указано иное.
Имена объектов
При создании большого количества объектов необходимо иметь эффективпх к
систему7 их отслеживания. Для этой цели диспетчеру объектов необходимы:
я способ отличить один объект ОТ другого;
метод поиска и выборки заданного объекта.
Первое требование выполняется благодаря тому, что объектам можно па
начать имена. Тем самым системы расширены по сравнению с тем, что обычно
лредоставляется большинством ОС — способностью именовать некоторые pi
урсы, файлы, каналы или блоки совместно используемой памяти. В отличие от
других ОС. исполнительная система NT позволяет назначать имя любому ресур-
су, который представлен объектом.
Второе требование, возможность поиска объекта, также выполняется бла-
’одаря тому, что объекты имеют имена. Если диспетчер объектов хранит объек
гы по именам, то он может провести поиск объекта по его имени.
Имена объектов позволяют выполнить и еще одно требование дают
троцессам возможность совместно использовать объекты. Пространство плен
объектов исполнительной системы NT является глобальным, доступным всем
троцессам в системе. Один процесс может создать объект и поместить его имя
i глобальное пространство имен, а другой процесс может открыть описатель
(энного объекта, указав его имя. Если объект нс предназначен для совмсстпоп»
«пользования подобным образом, то сто создателю не нужно присваивав
объекту имя.
Для повышения эффективности диспетчер объектов нс ищет имя объекта
всякий раз, когда кто пибудь использует объект. Поиск но имени осуществляет
•я лишь в двух случаях. Во-первых, когда процесс создает новый объект,,mcnci
тер объектов, прежде чем поместить имя в глобальное пространство имен, осу
цсстъляет поиск по нему, чтобы убедиться, что оно уже нс присвоено дрхтому
объекту. Во-вторых, когда npoiiccc открывает описатель имш юваш юго объект я.
(испетчер объектов осуществляет поиск по имени, находит объект и возврата
*т его описатель; после этого для ссылок па объект вызывающий процесс н<
юльзует возвращенный описатель. При поиске имени диспетчер объектов по
июляет указать, игнорировать или различать регистр букв, что обеспечнвас!
тоддержку POSIX п других сред, где учитывается регистр букв в именах файлов
Имена объектов являются глобальными для данного компьютера (или для
ясх процессоров на многопроцессорной машине), по не видимы по сети. Од-
тако для доступа к именованным объектам, расположенным па другой машине.
диспетчер объек тов предоставляет средство перехвата — так называемый метод
разбора. Например, диспетчер ввода вывода, реализующий сервисы для файло-
вых объектов, расширяет функции диспетчера объектов для обеспечения доступа
к удаленным файлам. 11ри получении запроса на открытие удаленного файлового
объекта диспетчер объектов вызывает метод разбора, что позволяет диспетчеру'
ввезла вывода перехватить запрос и направить его сетевому редиректору — драй-
веру для доступа к файлам по сети. Процесс сервера на удаленной машине
Windoyvs NT вызывает диспетчер объектов и диспетчер ввода—вывода той систе-
мы для поиска объекта и возвращения информации обратно по сети. Будущие
расширения системы смогут использовать то же самое средство перехвата дис-
петчера объектов для управления другими удаленными объектами. (Методы опи-
саны подробнее в разд. 3.2.3; поддержка се тей в Windows NT описана в гл. 9.)
3.2.1.1 Каталоги
При определении структуры имен объектов основным ограничением для раз-
работчиков были файловые системы MS-DOS и POSIX, в которых существуют
иерархические схемы имен файлов и каталогов. В исполнительной системе NT
фаготы и каталоги файлов представлены как объекты; таким образом, чтобы
выполнять поиск файловых объектов, диспетчер объектов обязан понимать
формат имен файлов. Следовательно, имеет смысл, чтобы имена объектов напо-
минали имена файлов.
Имена объектов NT имеют некоторые характеристики имен файлов как
MS-DOS, так и POSIX. На рис. 3~3 изображена иерархия имен объектов NT в
виде дерева.
Обратите внимание, что корнем иерархического дерева является обрап 1ая
косая черта ( \), как в MS-DOS. Листовые узлы представляют отдельные объекты,
а промежуточные узлы — имена каталогов объектов. Для получения имени
объекта следует начать из корня и пройти до данного объекта по всей иерархии.
Как в MS-DOS и OS/2, для разделения имен при указании пути используется об-
ратная косая черта.
Объект-каталог объектов (object directory object) — это средство под-
держания изображенной выше иерархической структуры имен диспетчером
Рис. 3-3. Иерархия имен объектов.
объектов. Он является аналогом каталога файловой системы и содержит имена
других объектов, возможно, даже других каталогов объектов. Подсистема
Win32 и другие подсистемы, равно как н компоненты исполнительной систе-
мы NT, могут создавать произвольные иерархии каталогов обгектов для хране-
ния именованных объектов.
На рис. 3—I показана обобщенная сводка важнейших, уникальных характе-
ристик объекта-каталога объектов. На этом и других рисунках в данной книге
тип объекта (object type) обозначает описываемый класс объектов. Атрибуты
тела объекта (object body attributes) обозначают поля данных, хранящиеся в
телах объектов этого типа. Сервисы (services) — это базовые системные сервисы,
предоставляемые некоторым компонентом исполнительной системы NT для ра-
боты с атрибутами объекта. (Атрибуты из заголовка объекта не показаны, так как
они одинаковы для объектов всех типов. Аналогично, универсальные объект
ные сервисы, описанные выше, работают с объектами всех типов.)
Тип объекта
трибуты тела объекта
Сервисы
Каталог объектов
Список имен объектов
Создать каталог объектов
Открыть каталог объектов
Опросить каталог объектов
'ис. 3-4, Объект-каталог объектов6.
Сервисы создания и открытия используются для создания каталогов
бъектов и открытия их описателей. После того, как поток открыл описатель
аталога объектов (с доступом по записи), он может создавать друтие объекты и
ометцать их в этот каталог.
Сервис опроса позволяет просматривать список имен объектов, храня-
(ихся в каталоге. Объект-ка талог объектов содержит достаточно информации,
гобы транслировать имена объектов в указатели на сами объекты. Диспетчер
бъектов использует эти указатели для создания описателей объектов, которые
и возвращает программам пользовательского режима.
Каталоги объектов могут создаваткя как кодом ядра, так и кодом пользо-
|тельского режима (таким как подсистемы). Например, диспетчер ввода-выво-
i создает каталог с именем \Dcvicc, в котором хранятся имена объектов, прсд-
авляющих устройства ввода—вывода.
Трио объектных сервисов создания, открытия и опроса часто встречается
11СПОЛНИТСЛЫЮЙ системе NT. Система ввода вывода реализует сервис откры
я файла для своих файловых объектов, а диспетчер объектов — сервис созда-
1Я процесса для своих объектов—процессов. Хотя разработчики NT рассмат-
акос н«отражение объектов шешекя упрощенной нерснен формата. ирелюжениок) IIinepoM Ко
• и Эдвардом Йордоном в кише < tb/ccl Oriental Analysis (Englewood Chits. N I. ITeniicv- Hall I‘>X1)
ривали возможность использования единого, вирзуалыюго сервиса создания
объекта. такая процедура на (2 была бы очень сложной, так как набор парамет-
ров, необходимый для инициализации, к примеру, файлового объекта, заменю
отличается оттого, который нужен дня инициализации объекта—процесса. Еди -
ная процедура на С становилась бы все более сложной по мере добавления к
системе новых типов объектов. Кроме того, при всяком вызове потоком объект-
ного сервиса диспетчеру объектов пришлось бы нести дополнительные наклад-
ные расходы на определение типа объекта, на который ссылается описатель, и
вызов соответствующей версии сервиса. Но этим и другим причинам сервисы
создания, открытия и опроса реализованы отдельно для каждого типа объектов.
3.2.1.2 Домены
Пространство имен обьсктов образует как бы зонтик, под которым можно раз-
местить автономные наборы объектов, называемые доменами объектов (object
domains), тем самым расширяя пространство объектов. Диспетчер ввода-выво-
да, например, — это вторичный диспетчер объектов, управляющий доменом
объектов, который состоит из дисковых файлов, каталогов и устройств. Дис-
петчер объектов дает системе ввода-вывода возможность упрятать объекты
файловой системы в листовом узле пространства имен. Предположим, напри-
мер, что структура каталогов па гибком диске такова:
В пространстве имен объектов эта структура каталогов выглядит как на
рис. ,5—5. Каждое имя в изображенном дереве представляет объект исполни-
тельной системы NT. Пространство имен файловой системы присоединено к
пространству имен объектов под именем \Dcvice\FloppyO.
Когда пользователь Microsoft Excel for Windows пытается открыл» файл
A:\budget\accorints.xls, диспетчер объектов открываем описатель файлового
объекта с именем \Device\FloppyC)\budgct\accounts.xls.,’^B этой цели диспетчер
объектов просматривает свое пространство имен до тех пор, пока не дойдет до
объекта FloppyO, являющегося специальным объектом-устройством, с которым
связан метод разбора. Тогда диспетчер объектов приостанавливает поиск имени
н вызывает метод разбора, передавая ему имя \budgct\accounts.xls. Метод разбо-
ра реализуется системой ввода- вывода, которая обращается к соответствующей
файловой системе для поиска и открытня файла на гибком диске. Дальнейшее
описание методов см. в разд. 3.2.3.
•>го упрощенное описание мсханн nia. рассмлринаемою и слсд\ кинем pa civic.
Пространство имен
диспетчера объектов
Рис. 3-5. Структура объектов.
Символические связи
В некоторых файловых системах (например, в некоторых системах IINIX) сим
волическая связь даст пользователю возможность создать имя файла или катало-
га, которое при его использовании транслируется ОС в другое имя файла пли
каталога. Это простой метод неявного совместного использования файлов или
содержимого каталога — путем создания перекрестной ссылки между разными
ка талогами в обычно иерархической структуре каталогов.
Диспетчер объектов NT реализует объект, называемый объект—симва ш -
ческая связь (symbolic link object), который выполняет аналогичные функции
для имен объектов в его пространстве объектов. При ссылке на имя объекта
символической связи диспетчер объектов проходит по своему пространству
имен до тех пор, пока не дойдет до этого объекта. Далее он просматривает со-
держимое символической связи и находит строку, которую подставляет вместо
имени этой связи. Затем вновь производится поиск имени. Символическая связь
Тип объекта
Символическая связь
тела объекта
Сервисы
Строка для подстановки
Время создания
Создать символическую связь
Открыть символическую связь
Опросить символическую связь
:. 3-6. Объект-символическая связь.
Глава 3. Диспетчер объектов и контроль доступа
может встретиться в любом месте строки—имени объекта. На рис. 3—6 показаны
атрибуты и сервисы для типа объектов ‘‘символическая связь’’.
Один из примеров использования символических связей исполнительном
системой NT — это трансляция имен устройств MS DOS в имена объектов
Windows NT. В MS-DOS гибкие и жесткие диски обозначаются как А:, В:, С: и г. д.
Более тою, пользователь може т добавить новые имена устройств или псевдоус-
тройств, например, создав дополнительные разделы на жестком диске пли на-
значив имя устройства сетевому каталогу па удаленной машине. I !ослс их созда-
ния эти имена должны быть видимы всем процессам в системе.
Подсистема Win32 делает буквенные обозначения дисков защищенными
глобальными данными, помещая их в пространство имен диспетчера объектов.
Специально для этой цели создается особый каталог объектов, как показано ниже:
DosDe vices
При создании пользователем или приложением нового обозначения дис-
ка подсистема Win32 добавляет еще один объект в каталог объектов
\DosDeviccs. Однако объекты, представляющие настоящие физические устрой-
ства, располагаются в других местах дерева, как изображено на рисунке:
PartitionO
Partition 1
Объекты с
именами А:. В:, С: и т. д. — это символические связи. Каждая
из них содержит имя объекта—физического устройства, к которому отно-
сится буква. Таким образом, если пользователь Excel for Windows открывает
электронную таблицу, хранящуюся в A:\bndget\accounts.xls, то подсистема
Win32 преобразует это имя п открывает описатель файлового объекта с
именем \DosDcviccs\A:\budget\accounis.xls. Для поиска файлового объекта
диспетчер объектов проходит по дереву имен объектов, пока не найдет
объект под именем А: и не обнаружит, что он является символической свя-
зью. Он проверяет содержимое символической связи и находит в ней строке
\Device\FloppyO, как показано ниже:
ОВЫ WINDOWS NT
Диспетчер объектов берет строку, найденную внутри символической
ссылки, и добавляет к се концу остаток оригинальной строки (\Device\Floppyu
плюс \budgct\accounts.xls). После этого он вновь начинает поиск файлового
объекта с корня дерева.
Символические ссылки позволяют подсистемам (или другим программам)
создавать для объектов исполнительной системы псевдонимы, которые подси-
стемы при необходимости могут изменят!.. Болес того, подсистема может по-
лучить выигрыш в производительности, сохраняя глобальные данные, такие
как имена устройств, непосредственно в исполнительной системе NT, а нс в
собственном адресном пространс тве. Дальнейшее обсуждение вопроса произ-
водительности подсистем см. в гл. 5, “Windows и защищенные подсистемы”.
Описатели объектов
Хотя имена объектов важны для хранения и совместного использования объек-
тов, они используются нс часто. Процесс указывает имя объекта, когда он созда-
ет объект или открывает его описатель. После этого процесс использует описа-
тель объекта. Ссылка на объект при помощи сто описателя выполняется быст-
рее, чем по имени, так как диспетчер объекта может опустить поиск имени '
найти объект непосредственно.
Описатель объект а NT — это индекс в специфичной для процесса таблиц’
объектов (object table). Таблица объектов процесса содержит указатели на исс
объекты, описатели которых открыты процессом. Процесс может получить
описатель объекта, создав объект, пли открыв описатель существующего объем
та, или унаследовав описатель от другого процесса, пли получив дубликат он’*'
сателя из другого процесса. На рис. 3-7 показана связь между процессом п ев’
таблицей объектов.
Каждый вход таблицы объектов содержит предоставленные права дехтук-1
для соответствующего описателя и его[н.’лаои наследования (inheritance design-1'
tion) иными словами, получат ли процессы, созданные данным процессе'1
копию этою описателя в своих таблицах объектов. Хотя термин описанн’11'
(handle), строго говоря, относится только к индексу в таблице, разработчик11
иснользчтот этот термин и для обозначения данных, хранящихся в стххгветст
ющем входе таблицы
Глава 3. Диспетчер объектов и контроль доступа
Таблица
объектов
Рис. 3-7. Структура таблицы объектов.
Два процесса совместно используют объект, если оба они от крыли его опи-
сатели. Каждый из этих описателей уникален, как показано на рис. 3 8.
Создатель объекта определяет, могут ли описатели объекта наследо-
ваться из процесса теми процессами, которые он создал. Это средство по-
зволяет поддерживать среды, включая Win32 и POSIX, разрешающие насле-
дование ресурсов.
При завершении процесса соответствующий объект—процесс становится
кандидатом на удаление из системы (в зависимости от того, используется ли
он все еще другим процессом, как будет описано далее). Прежде чем удалить
Рис. 3-8. Совместное использование объекта.
ОВЫ WINDOWS NT
объект-процесс, диспетчер объектов вызывает метод "удалить” дня обьекгог
процессов, который закрывает все описатели в таблице объектов процесс
(подробнее см. разд. 3.2.3)
1 Удержание объектов
Так как все процессы пользовательского режима, осуществляющие доступ 1;
некоторому объекту, должны вначале открыть его описатель, то диспетчер объец.
тов может легко отслеживать, сколько процессов, п даже какие именно, исполь-
зуют данный объект. Отслеживание открытых описателей — это первый т.н ,,
реализации удержания объектов (object retention), т.е. сохранения временных
объектов только на то время, пока они используются. с последующим удаление м
Удержание объектов включает две фазы. Первая фаза называется удержа-
нием имени (name retention) п управляется количеством от крытых описать- к й
данного объекта. Всякий раз, когда процесс открывает описатель обьекта. дне
петчер объектов увеличивает счетчик открытых описателей в заголовке объек га
(см. рис. 3-1-) После того, как процесс закончил работу с объектом и закрыл
имеющиеся у него описатели данного объекта, диспетчер объектов уменьшает
счетчик. Когда счетчик обнуляется, диспетчер объектов удаляет объект из своего
пространства имен. В результате новые процессы не могут от крыть описатели
данного объекта. (Имена постоянных объектов не удаляются, поскольку >гп
объекты представляют такие сущности, как физические устройства, которые
остаются на месте, даже если их не использует пи один процесс. Прежде чем
удалить постоянный объект, ОС должна сделать его временным.)
Вторая фаза удержания объектов — это прекращение удержания (т.е. уда-
ление объектов), когда они более не используются. Так как ОС обычно осуще-
ствляет доступ к объектам посредством указателей, а нс oni юателей, диспетчер
объектов должен также у читывать количество указа телей на объект, которое
он передал процессам < Х'. Всякий раз при выдаче нового указателя па объект
диспетчер объектов увеличивает счетчик ссылок объекта (reference count);
когда поток ОС заканчивает работу с объектом, он обращается к диспетчеру
объектов для уменьшения счетчика ссылок. Таким образом. даже после того.
как счетчик описателей достиг нуля, счетчик ссылок может оставаться положи-
тельным, указывая, что ОС продолжает использовать объект. В конце концов
счетчик ссылок обнуляется. Когда это происходит, диспетчер объектов удаляет
объект из памяти.
Благодаря такой реализации удержания объектов приложение гарант пр'-
ет, что объект и его имя остаются в памяти, просто сохраняя открытым описа-
тель этого объекта. I (рограммистам, пишущим приложения, которые состоя г
двух или более взаимодействующих междусобой процессов, не нужно беспоко-
иться о том, что один процесс .может удалить обтжкг, прежде чем другой закон-
чит работу' с' ним. Кроме того, закры тие описателей объекта приложениями |К
приводит к удалению объекта, если его по прежнему использует ОС. Например
один процесс может создать другой процесс для выполнения некоторой пр'1"
граммы в фоновом режиме; сразу же после этого первый процесс закрыв.к'1
описатель второго. Так как второй процесс нужен ОС для выполнения пр’'
граммы, то она сохраняет ссылку на объект процесс. Только после- того кз'-
с]>оповая программа закончит выполнение, диспетчер объектов уменьшит счО'
чик ссылок второго процесса и затем удалит этот процесс.
Глава 3. Диспетчер объектов и контроль доступа
3 2-2-2 Учет использования ресурсов
Учет использования ресурсов, так же как и удержание объектов, тесно связан с
использованием описателей объектов. Если у объекта сеть положительный счет-
чик открытых описателей, это означает, что некоторый процесс использует
данный ресурс. Это также означает, что некоторый процесс ‘‘платит ” за память,
занятую объектом. Когда счетчик описателей обьекта обнуляется, процесс, пе-
ред тем использовавший объект, не должен более за это платит ь.
Многие ОС используют квоты для ограничения доступа процессов к сис-
темным ресурсам. Однако типы квот, налагаемых на процессы, иногда бывают
слитком разнообразными и сложными, а код их учета разбросан но всей систе-
ме. Например, пусть в некоторой ОС компонент ввода-вывода учитывает и огра-
ничивает число файлов, которые может открыть процесс, в то время как компо-
нент, отвечающий за распределение памяти, накладывает ограничения па объем
памяти, который могут использовать потоки процесса. Компонент управления
процессами ограничивает число процессов, которые может создать пользова-
тель, или устанавливает максимальное число потоков в этих процессах. Каждое из
этих ограничений отслеживается и выполняется различными компонентами (XI
В противоположность этому, диспетчер объектов NT обеспечивает цент-
рализованное средство учета использования ресурсов. Каждому пользователю
назначаются предельные размеры квот, ограничивающие суммарный объем
системной памяти, который может быть использован его процессами. Соответ-
ственно, заголовок каждого объекта содержит атрибут, называемый “расход кво-
ты” и содержащий значение, которое диспетчер объектов вычитает ггз выделен-
ной процессу квоты, когда поток этого процесса открывает описатель данного
объекта. Потоки процесса могут гга протяжении своей жизни открыть много
описателей, и всякий раз диспетчер объектов вычитает определенный объем ггз
квоты процесса. Если процессы пользователя открыли слитком много описате-
лей и израсходовали всю его квоту, то их потокгг должггы закрыть некоторые
описатели, прежде чем они смогут открыть новые. Диспетчер объектов, таким
образом, ограничивает использование ресурсов процессом (и. в конечном сче-
те, пользователем), учитывая объем памяти. занятой объектами, описатели кото-
рых открыты процессом. (Помимо квоты использования объектов, диспетчер
процессов NT устанавливает квоту на использование времени процессора каж-
дым процессом пользователя.)
3.2.3 Методы объектов
Диспетчер <хтг>ектов использует их сходные черты, чтобы работать с объектами
единообразно. Однако, у объектов есть и различия, иногда весьма существенные.
Диспетчер объектов был бы слишком большим и сложным, еелгг бы ему при-
шлось учитыггать вес особенности различных типов объектов. Он также долже> 1
был бы изменяться при добавлении к системе нового типа объектов. Чтобы из-
бежать этого, диспетчер объектов предоставляет возможности перехвата. кото-
рые другие компоненты исполнительной системы NT могут исполыювать для
выполнения задач, уникальных для их типов объектов. Эти средства перехвата
называются .методами объектов (object method).
Когда компонент исполнительной системы создает новый тип обьекта.
он может зарегистрировать в диспетчере объектов одни или несколько мето-
дов. После этого диспетчер объектов вызывает данные методы в строго онре-
>ВЫ WINDOWS NT
деленные моменты жизни объекта этого типа: обычно. когда объект создастся,
удаляется пли некоторым образом модифицируется. Методы, поддерживаем ьщ
дпепетчером объектов, перечислены в табл. 3—5.
Таблица 3-5. Методы объектов
Метод Когда вызывается
Открыть При открытии описателя объекта
Закрыть При закрытии описателя объекта
УДалить Прежде чем диспетчер объектов удалит объект
Запросить имя Когда поток запрашивает имя объекта, который находится то вторичном домене объектов, например файла
Разбор При поиске диспетчером объектов имени объекта, существующего во вторичном домене объектов
Защита При считывании или изменении процессом параметров защиты объекта, который находится во вторичном домене объектов, например файла
Пример использования метода “закрыть” имеет место в системе ввода-вы-
вода. Диспетчер ввода-вывода регистрирует метод закрытия для файлового типа
объектов, а диспетчер объектов вызывает данный метод всякий раз. когда он зак
рывает описатель файлового объекта. Метод “закрыть” проверяет, установлены ли
процессом, закрывающим файл, какие-либо блокировки этого файла, и если да.
то удаляет их. Проверка на наличие блокировок файла нс является действием, ко-
торое может или должен осуществлять непосредственно диспетчер объектов.
Перед удалением из памяти временного объекта диспетчер объектов вы-
зывает метод “удалить”, если он был зарегистрирован. Диспетчер виртуальной
памяти для объект ов типа “секция”, например, регистрирует данный метод, ко-
торый освобождает физические- страницы, занятые секцией. Метод также гаран-
тирует, что все внутренние ст руктуры данных, выделенные для секции диспетче-
ром виртуальной памяти, будут удалены перед удалением объекта-секции, Эту
работу тоже нс может выполнить диспетчер объектов, так как он ничего нс 31 ia-
ст о внутренних принципах работы диспетчера виртуальной памяти. Методы
удаления для других типов объектов выполняют аналогичные функции.
Метод “разбор” (и аналогично, метод "получить имя”) позволяет диспет-
черу объектов переложить задачу поиска объекта на вторичный диспетчер
объектов. Вторичный диспетчер объектов находтгг объект. расположенный вне
пространства имен диспетчера объектов, в другом домене объектов. Простей'
тлим примером является система ввода—вывода. Посмотрим стцс раз на рттеуно*'
(справа), который уже приводился выше.
Объект с именем Floppy!) — это объект-устройство. особый тип объек н>1!
определяемый и используемый системой ввода-вывода. В пространстве iimci*
диспетчера объектов объект-устройство от ображает' т очку входа в до мет1
объектов файловой системы, о котором диспетчер объектов ничего нс знасг-
При создании типового объекта “устройство” система ввода вывода Iх”
гистрируст для него метод "разбор”. Когда диспетчер объектов ищет п'”'
объекта, он приостанавливает поиск, если ему встречается объект, имеют*11'
метод разбора. Диспетчер объектов вызывает- метод “разбор”, передавая с'1'
остаток имени обт>екта, которое нужно найти.
Iлава <5. Аиспетчер объектов и контроль доступа
Пространство имен
диспетчера объектов
Например, когда процесс открывает описатель объекта с именем \Devi-
ce\HoppyO\docs\resume.doc, диспетчер объекта проходит по своему дереву имен,
пока не достигнет объекта—устройства с именем FloppyO. Он обнаруживает,
что с этим объектом связан метод “разбор”, и вызывает данный метод, переда-
вая ему остаток имени объекта, которое он ищет в данном случае строку’
\docs\resume.doc. Метод разбора для объектов устройств — это процедура вво-
да-вывода. Процедура принимает строку имени и передаст се подходящей фай-
ловой системе, которая находит файл на диске и открывает его.
Объекты—символические связи, описанные в разделе 3-2.1.3, также транс-
лируются методом “разбор”. У типа объектов “символическая связь” имеется
свой такой метод. Метод получает имя, подставляет вместо него другое и вызы-
вает диспетчер объектов для повторного поиска объекта. (Если в новом имени
также имеется символическая связь, то метод “разбор” будет вызван еще раз.)
Метод “защита”, который используется системой ввода-вывода, похож на
метод “разбор”. Он вызывается всякий раз, когда поток пытается изменить ин-
формацию о защите файла. Эта информация для файлов имеет отличия но срав-
нению с другими объектами, так как храгштея в самом файле, а не в памяти.
Таким образом, для поиска и изменения информации о защите должна быть
вызвана система ввода—вывода.
3.3 Защита объектов
Унификация именования, гцтсдоставлеиия в совместное использование и счета
использования системных ресурсов уже дает достаточные основания для при
менения объектной модели в исполнительной системе NT; однако важнейшей
причиной этого, является, по всей вероятности, обеспечение защиты.
Операционная система должна быть защищена от “нападений” сразу па
iiccko.ii.ktix фронтах. Защищенная многопользовательская система должна за
)ВЫ WINDOWS NT
щнщать файлы, память п другие ресурсы каждого пользователя от других
пользователей. Опа должна защищать собственные данные, файлы и память 1ч
пользовательских программ. Она должна отслеживать попытки обхода защпаы
н г. д. Министерство обороны США определило средства, наличие которых у ().
делает се защищенной. Эти средства разделены па семь уровней защиты, нриче ч
каждый последующий более строг, чем предыдущий .
Для соответствия уровню С2, исходной цели для W indows NT, в ней доля,
ны присутствовать следующие с|эедства:
* Средство защищенной регистрации в системе требует, чтобы ноль ю-
ватсль идентифицировал себя посредством ввода уникального пдепиь
фикатора и пароля, прежде чем с.му будет предоставлен доступ к системе
Селективный контроль доступа позволяет владельцу ресурса опреде-
лять, кто имеет доступ к данному ресурсу и что они могут с ним де ла । ь
Владелец определяет это, назначая права доступа пользователю или
группе пользователей.
* Аудит обеспечивает возможность обнаружения и регистрации важных
событий, имеющих отношение к защите, или любой попытки создания,
использования или удаления системных ресурсов. Для учета пользова-
телей, выполнивших регистрируемое действие, используются их иден-
тификаторы.
' Защита памяти предотвращает чтение информации, записанной
кем-либо в память, после того как этот блок памяти был возвращен < >С
Перед повторным использованием память рсипициализируется.
Механизмы обеспечения безопасности, предоставляемые системой, требу-
ются пс во всех случаях применения Windows NT. 11оэтому система защиты по-
зволяет системному администратору, например, упрощать процесс регистра-
ции в системе, регулировать объем информации, помещаемой в журнал ауди та,
или отключать аудит совсем.
В тех случаях, когда предъявляются особые требования к безопасности,
например, в военных организациях, необходим еще более высокий уровень за-
щиты, чем тот. что исходно обеспечивается Windows NT. В связи с этим Wind< >ws
NT рассчитана на дальнейшее развитие до уровня защиты В2, известного под
названием “ Полномочный контроль доступа” (Mandatory’ Access Control), когда
каэвдому пользователю присваивается уровень полномочий и он не может пре-
доставить доступ к защищенным ресурсам пользователям с недостаточны'1
уровнем полномочий. Например, в секретных учреждениях правительства (ЛИ-'
одному' пользователю может быть присвоен уровень полномочий “Секретно :1
другому — “Совершенно секретно”. Полномочный контроль доступа гарантнрУ'
ст, что пользователь с уровнем полномочий “Совершенно секретно” нс сможс’1
предоставить первому пользователю доступ к какой-либо информации с гр’1'
фом “Совершенно секретно”, даже при помощи средств селективного контрой’
доступа. Кроме того, уровень В2 требует поддержки “отделений” (compart-
ments), изолирующих группы пользователей друг от друга. Этот тип защий’1
удобен в таких областях, как торговля цепными бумагами, где неавторизова!1'
IXpannieiit of IX-teibe TTusiccI (joni|x>ici System Evaluation Criteria. 1X)I> S2o’).2S-STO (IXxemlxT ГИТ*)
Глава 3. Диспетчер объектов и контроль доступа
пый доступ к информации о предложении акций или слиянии может вызван,
коп фл I ikt инте реет >в.
Система защиты W indows NT многогранна, однако, суп. селективного
контроля доступа и аудита (а в будущем и полномочного контроля доступа)
состоит и защите объектов. Главная идея, лежащая в основе системы защиты
Windows NT. — это создание шлюза, через который должен пройти каждый
пользователь системных ресурсов. Так как все системные ресурсы, защита ко-
торых может быть нарушена, реализованы как объекты, то таким шлюзом ста-
новится диспетчер объектов. Чтобы удостовериться в целостности системы за-
щиты Windows NT, нет необходимости тыкаться во все “закоулки" ОС; крити-
ческие операции обеспечения защиты выполняются в одном центре.
Следующие подразделы рассматривают защиту объектов с двух точек зре-
ния: во-первых, идентификация пользователей, во-вторых, управление досту-
пом пользователей к объектам.
3.3.1 Маркеры доступа
Чтобы контролировать, кто имеет право работать с объектом, система защиты
должна быть уверена, что пользователь правильно идентифицирован. Таким
образом, первая линия защиты в Windows NT — это требование, чтобы каждый
пользователь зарегистрировался перед началом работы.
Как описано в гл. 2, “Общие сведения о системе", неотъемлемая часть сис-
темы — защищенная подсистема, извест ная как подсистема защиты (security
subsystem), отвечает за аутентификацию (authenticating) пользователей, т.с. за
проверку того, что введенная пользователем при регистрации в системе инфор-
мация совпадаете информацией, хранящейся в базе данных защиты. После того,
как подсистема защиты определила, что регистрация аутентична, она создает
объект, который остается постоянно связанным с пользовательским процессом.
Этот объект называется маркером доступа (access token) и служит официаль-
ным удостоверением личности процесса, когда тот пытается использовать ка-
кой-либо системный ресурс. Пример маркера доступа показан на рис. 3—9
Первый показанный па рисунке атрибут — это личный пользовательский
идентификатор защиты (security ID), который обычно соответствует иденти-
фикатору, указываемому пользователем при регистрации. В больших организа-
циях идентификатор защиты также может включать в себя название подразде-
Идентификатор защиты:
Идентификаторы групп:
Привилегии:
Владелец по умолчанию:
Первичная группа:
ACL по умолчанию:
MARYH
ТЕАМ1
LOCAL
INTERACTIVE
WORLD
Нет
MARYH
ТЕАМ1
* АСЕ ----► АСЕ -----► АСЕ
Рис. 3-9. Гример маркера доступа.
)ВЫ WINDOWS NT
лсния или отдела пользователи! (например, ENGINEERINGMARYII). Идентифи-
каторы защиты групп создаются из списков идентификаторов пользователей.
Второй атрибут па рис. 3-0 это список групп, к которым принадлежи-!
MARYH. Windows NT задает несколько стандартных идентификаторов групп,
которые включены в маркер MARY II.
При попытке процесса открыть описатель объекта диспетчер объектов
вызывает справочный монитор защиты. Справочный монитор защиты получает
маркер доступа, связанный с процессом, и использует его идентификатор защи-
ты и список групп, чтобы определить, имеет ли процесс право доступа к объекту
Небольшое количество чувствительных к защите системных сервисов (та-
ких как создание маркера), также защищены от использования. Атрибут приви-
легий перечисляет все такие сервисы, к которым имеет право обращаться
пользователь. Большинство пользователей не имеет никаких привилегий.
В общем случае, пользователь, создавший объект, становится его владель-
цем и может решать, кто еще имеет доступ к объекту: Список контроля доступа
(access control list, ACL) по умолчанию, хранящийся в маркере доступа. — это
первоначальный список прав доступа, который присоединяется к создаваемым
пользователем объектам. Атрибут “первичная группа” позволяет собирать иден-
тификаторы защиты в группы для организационных целей. Это свойство при
сутствуст в некоторых средах ОС. включая POSIX.
Болес подробно идентификаторы защиты и списки управления доступом
описаны в следующем разделе. Теперь же обратимся к рис. 3-10. где изображены
атрибуты и сервисы, применимые к объектам маркерам доступа.
К сервисам создания, открытия и опроса добавляется еще сервис усга
новки. Установка атрибутов объекта — это распространенный сервис, предос-
тавляемый многими объектами исполнительной системы NT. Другие три сер-
виса предназначены для использования главным образом программами адми-
нистрирования защиты.
Тип объекта
Маркер доступа
Атрибуты тела объекта
Сервисы
Идентификатор защиты
Идентификаторы групп
Привилегии
Владелец по умолчанию
Первичная группа
ACL по умолчанию
Создать маркер
Открыть маркер
Запросить информацию маркера
Установить информацию маркера
Дублировать маркер
Скорректировать привилегии маркера
Скорректировать группы маркера
Рис. 3-10. Объект-маркер доступа.
Глава 3. Диспетчер объектов и контроль доступа
3.3.2 Списки контроля доступа
При создании любого объекта, включая файлы, потоки, события и даже марке-
ры доступа, ему присваивается дескриптор защиты*. Основной частью деск-
риптора защиты является список прав доступа к объекту, называемый списком
контроля доступа (ACL). Владелец объекта, которым обычно является его со-
здатель, обладает правом селективного контроля доступа к объекту и может изме-
нять ACL объекта, чтобы разрешить или запретить другим его использование. На
рис. З-Н упрощенно изображен файловый объект и его ACL
Каждый вход ACL называетсяжчениюи контроля доступа (access control
entry, АСЕ). АСЕ содержит идентификатор защиты и набор прав доступа. Пользо-
вателю с соответствующим идентификатором защиты перечисленные права
доступа могут быть разрешены, запрещены или разрешены с аудитом. Сумма
прав доступа, предоставленных отдельными АСЕ, формирует набор прав досту-
па, предоставляемых АСЕ
Предположим, что Вы хотите, например, просмотреть файл. Если ACL фай-
лового объекта содержит АСЕ с Вашим идентификатором защиты или с иденти-
фикатором защиты одной из Ваших групп, и этот АСЕ содержит право доступа
‘ чтение данных”, то просмотр файла Вам разрешен. В дополнение к этому, если
операцг 1я, которую Вы пытаетесь выполнить, является привилегированной, та-
кой как создание маркера доступа, io Вы должны иметь привилегию создавать
маркер доступа. В противном случае доступ будет отменен.
Как показано на рис. 3-11, АСЕ может также содержать идентификатор защи-
ты группы. DAVEC имеет доступ к файловому объекту по чтению, члены группы
ТЕА.М1 — по чтению и записи, а все другие пользователи — права на исполнение
Заголовок
объекта
Файловый объект Список контроля доступа
Рис. 3-11. Список контроля доступа (ACL).
Чтобы определить, какой ACL должен быть назначен новому объекту,
система защиты применяет три взаимоисключающих правила, в приведенном
ниже порядке:
Если ACL явно задан при создании объекта, то система защиты присва-
ивает объекту данный АСЕ
” Из этого правила есть исключения.Дескрипторы защиты необходимы только тем объектам, к<лхь
рыс будут использоваться более чем одним процессом. К этой группе относятся все поименованные
объекты, а также как поименованные, так и безымянные процессы, потоки и маркеры.
ЭВЫ WINDOWS NT
Если ACL ис задан и у объекта есть имя, то система защиты ищет А(.|
каталога объектов, в котором будет сохранено имя нового объекта. I |е.
которые АСЕ каталога объектов могут быть обозначены как “паеледм-
мыс” — это означает, что они должны быть присвоены новым объектах,
созданным в данном каталоге. Если такие наследуемые АСЕ прнсу-ivi щ_
ют, то система защиты составляет из них АСЕ, который она назначат
новому объекту.
Ж Если ин один из первых двух случаев нс имее т места, то система защит,,,
присваивает новому объекту' ACL ио умолчанию из маркера дост\ца
вызывав>щст<> прозjecca.
Кроме ACL, дескриптор защиты объектов содержит' поле, управляющее
аудитом объекта.Лудит (auditing) означает способность системы защиты "шпи-
онить’' за выбранными объектами и их пользователями и генерировать сообще-
ния или оповещения, если кто либо попытается выполнить над объектом опе-
рацию, использование которой ограничено. Например, система защиты может
выполнять аудит попыток чтения или изменения системного файла. Если кто-
то пытается модифицировать данный файл, то система защиты помещает сооб-
щение в журнал аудита вместе с идентификатором защиты пользователя. Сис-
темный администратор может генерировать отчеты, составлен!пяс по и!к]х»р-
мации из этого журнала. Дчя систем с очень высоким уровнем защиты система
защиты может даже генерировать звуковые или визуальные сигналы тревоги i ia
машине администратора, когда происходит некоторое действие. Аудит умень-
шает риск незаконного проникновения в компьютер.
Как все это работает вместе
Маркер доступа идентифицирует процесс (и сто потоки) для ОС, тогда как дет к-
риптор защиты перечисляет, какие процессы (или группы процессов) имеют дос-
туп к объекту. Когда поток открывает описатель объекта, диспетчер объектов и
система защиты сопоставляют эту информацию, чтобы определить, следует ли
предоставить вызывающему по току запрашиваемый им описатель.
На рис. 3—12 показано, что происходит, когда пользователь LEES открыва-
ет описатель, запрашивая доступ синхронизации к объекту—событию.
Проверяя АСЕ, система защиты просматривает список, начиная с первого
АСЕ. Когда опа находит идентификатор защиты вызывающего или его группы,
она останавливает поиск и проверяет, разрешает ли данный АСЕ доступ запра-
шиваемого типа. Если АСЕ, разрешающий доступ, найден, то поиск прекращает-
ся, и вызывающему возвращается описатель. Если система достигает конца спис-
ка, нс найдя идентификатора защиты вызывающего или его группы, то д<х'ту11
запрещается.
На рис. 3-12 ACL объекта-события разрешает LEES доступ синхронизаций
в своем первом элементе. Так как LEES запрашивал именно этот тип доступа-
система защиты немедленно прекращает поиск, и диспетчер объектов возвра-
щает LEES описатель, имеющий доступ синхронизации к данному событии’
Обратите- внимание, что третий АСЕ запрещает LEES доступ синхронизации на
основании членства LEES в группе ТЕАМ2. Однако из-за порядка расположения
АСЕ в ACL в данном случае третий АСЕ игнорируется. (Это несколько надуман-
Глава 3. Диспетчер объектов и контроль доступа
Маркер доступа
Идентификатор защиты:
Идентификаторы групп:
LEES------
ГЕАМ1
ТЕАМ2
LOCAL
INTERACTIVE
WORLD
Нет
Привилегии:
Объект-событие
Рис. 3-12. Проверка прав доступа к объекту.
ный пример, так как система в общем случае помещает АСЕ, запрещающие до-
ступ, в начало списка.)
Делать такую проверку при всяком использовании описателя процессом
было бы неэффективно. ACL может содержать много записей, процесс может за
время своей работы осуществлять доступ ко многим объектам, и одновременно
могут быть активными несколько процессов. Поэтому проверка осуществляется
только при открытии описателя, но не при всяком его использовании. (Обрати-
те внимание, что поскольку код в режиме ядра использует для доступа к объек-
там указатели, а нс описатели, то проверка прав доступа не производится, когда
объект используется самой ОС. Другими словами, исполнительная система NT
“доверяет’’ самой себе в смысле защиты.)
Когда LEES воспользуется описателем в следующий раз, диспетчер объек-
тов просто сравнит предоставленный доступ (синхронизацию), хранящиеся в
описателе, с типом доступа, который подразумевается вызываемым сервисом.
Если вызывается сервис ожидания, то вызов будет успешным. Если же будет вы-
дан запрос на установку7 события, то сервис потерпит неудачу. Для того, чтобы
запросить ус тановку' события, LEES следовало запросить при открытии первого
описателя доступ как синхронизации, так и изменения состояния; или же теперь
нужно открыть новый описатель, запрашивая доступ изменения состояния.
Заметьте, что после того, как процесс успешно открыл описатель, предо-
ставленные ему права доступа не могут бы ть отозваны системой защиты, даже
НОВЫ WINDOWS NT
если изменился ACL объекта. Ему по—прежнему приписывается старый опи< а.
тель, так как разработчики решили, что эффективные проверки защиты важпеу
чем возможность отзыва прав дос тупа. Последнее потребовало бы полной пр().
верки прав доступа при всяком использовании описателя, а не только при сг,
первоначальном задании, как это делается сейчас. Повышение производительно,
сти, достигаемое за счет запоминания предоставленных прав доступа непосрсц.
сгвепно в описателе, довольно велико, особенно для объектов с длинным ACL
Заключение
Объекты исполнительной системы NT служат в Windows NT средством унпфи.
кации. Они обеспечивают унифицированное управление системными ресхр.
сами. С ними связано и выполнение таких важных задач, как именование, со-
вместное использование и защита ресурсов. Кроме того, они предоставляют
набор примитивов, используемых подсистемами сред для реализации соб-
ственных версий объектов и объектоподобных ресурсов. Каждая подсистема
среды использует объекты исполнительной системы для обеспечения средств
и ресурсов, которые требуются ее клиентским приложениям.
Объекты пользовательского режима, представленные в этой главе, основа-
ны на наборе более примитивных объектов, реализованных ядром NT. Обсужде-
ние объектов ядра и их возможностей отложено до гл. 7, “Ядро” В следующей
главе мы рассмотрим два специальных объекта, без которых Windows NT не
может функционировать: процессы и потоки.
ГЛАВА 4
ПРОЦЕССЫ И ПОТОКИ
В первых версиях MS-DOS пользователи могли запускать одновременно нс
более одной программы. Им приходилось ждать, пока она закончит работу, и
затем запускать другую. Под Windows, однако, пользователи могут одновремен-
но запускать несколько программ или даже несколько копий одной програм-
мы. Отсюда видна одна тонкость, важная для данной главы: в чем различие
между программой и процессом? Программа (program) — это статическая пос-
ледовательность команд, тогда как процесс (process) — это программа и сис-
темные ресурсы, необходимые для ее работы.
Процесс является субъектом владения ресурсами и единицей работы. Он
служит ОС средством организации многих задач, которые она должна выпол-
нять. ОС выделяет каждому процессу порцию системных ресурсов н гаранти-
рует, что программа каждого процесса будет направляться па исполнение в
определенном порядке и своевременно.
В общем случае ОС содержат блок кода, управляющий созданием и удале-
нием процессов, а также отношениями между ними. Этот код называется струк-
турой процессов (process structure) и в Windows NT реализован диспетчером
процессов (process manager). Марк Люковски (Mark Lucovsky), один из разра-
ботчиков Windows NT, писавший ранее компоненты структуры процессов как
для системы UNIX, так и для ОС, основанной на использовании объектов, струк-
турировал и написал диспетчер процессов исполнительной системы NT. Он
определил его основную задачу одной фразой: предоставить набор базовых
сервисов процесса, который подсистемы среды могли бы использовать для
эмуляции своих собственных уникальных структур процессов. Цель такого под-
хода — обеспечить в Windows NT несколько сред ОС, работающих в пользова-
тельском режиме.
В разных ОС процессы реализованы по-разному. Процессы различаются
своим представлением (структурами данных), способами именования н защи-
ты и отношениями между собой. Базовые процессы NT имеют ряд характери-
стик, отличающих их от процессов других ОС:
Процессы NT реализованы как объекты, и доступ к ним осуществляет-
ся посредством объектных сервисов.
В адресном пространстве процесса NT может исполняться несколько
потоков.
* Как объект-процесс, так и объект-поток имеют встроенные возмож-
ности CT IIIXpOIII 133ЦИИ.
ОВЫ WINDOWS NT
Диспетчер процессов NT не поддерживает между создаваемыми ну
процессами отношении родитель-потомок или каких-либо иных
В этой главе рассматривается природа процессов вообще и струю у
процессов исполнительной системы NT в частности. Глава начинается с oiip,..
деления понятия процесса, а затем рассматривается реализация пронес.,.,,,
диспетчером процессов NT. I I наконец обсуждается соот ношение между р,
сией процесса исполнительной системы NT н версиями процессов, кото, ....
подсистемы среды предоставляют прикладным программам.
Что такое процесс?
На самом высоком уровне абстракции процесс состоит из:
исполняемой программы, которая определяет начальный код и данные;
• закрытого адресного пространства (address space), т. е. набора адре-
сов виртуальной памяти, который процесс может использовать;
системных ресурсов, таких как семафоры, коммуникационные норны
и файлы, выделяемых ОС процессу во время выполнения программы
В Windows NT процесс, чтобы он мог рабо тать, должен включа ть четвер-
тый элемент:
Ч по крайней мере один поток управления (thread of execution).
Поток — это сущность внутри процесса, которую ядро NT направляет па
исполнение. Без него программа процесса не может выполняться.
В следующих подразделах процесс рассматривается более детально на-
чиная с его адресного пространства и заканчивая ресурсами. Затем следует
раздел, посвященный теме потоков.
Адресное пространство
Исходя из здравого смысла, какой-либо процесс не должен иметь неограни-
ченного права управления другими процессами. Одним из способов д<м пг
жения этого в Windows NT служит система виртуальной памяти (virtual
memory). С се помощью программисты (и создаваемые ими процессы) полу
чают логический образ памяти, который не совпадает с се физической струг’'
турой (см. рис. 4 I).
При всяком обращении процесса по виртуальному адресу’ система впР"
туальной памяти транслирует этот адрес в физический. Опа также предотвр-1'
щает непосредственный доступ процесса к вирт уальной памяти, запятой ДР>'
гимн процессами или ОС. Дня исполнения кода ОС или доступа к памяти <)(
ноток должен исполняться в привилегированном режиме процессора п|Ь
называемом режиме ядра (kernel mode). Однако большинство процессов
это процессы пользовательского режима, т. е. такие, потоки которых исно-1'
няются в основном в непривилегированном режиме процессора — пользова-
тельском режиме (user mode).
Глава 4. Процессы и потоки
Ноток пользовательского режима получает доступ к ОС, вызывая некото-
рый системный сервис. Когда поток вызывает сервис, процесс перехватывает
сто и переключает из пользователккого режима в режим ядра. 0(2 получает
управление потоком, проверяет аргументы, переданные потоком сервису, пос-
ле чего исполняет сервис. Перед возвратом управления пользовательской про-
грамме ОС переключает поток обратно в пользовательский режим. Таким об-
разом, ОС защищает себя и свои данные от просмотра и модификации пользо-
вательскими процессам! г.
Данная глава посвящена процессам пользователккого режима, которые в
любой момент времени составляют большую часть процессов, исполняемых
Windows NT. В пользовательском режиме исполняются как прикладные про-
граммы, так и защищенные подсистемы Windows NT. Последние представляют
собой процессы—серверы пользовательского режима, реализующие важные
функции системы. Они реализованы как серверы, чтобы упростить базовую ОС
и обеспечить ее расширяемость. Подсистемы работают в пользовательском ре-
жиме, так что адресное пространство каждой из них защищено от прикладных
процессов и от других подсистем (подробнее см. гл. 5).
Образ для
программиста 1
Виртуальное адресное
пространство
' FFFFFFFFh
OOOOOOOOh
Система
(2 Гбайт)
Пользователь 1
(2 Гбайт)
Физическая
память
Резидентная
система
Пользователь 2
Свободно
Пользователь 1
Пользователь 2
' FFFFFFFFh
Образ для
программиста 2
OOOOOOOOh
Образ для
программиста 3
' FFFFFFFFh
т/
\
\
\
\
\ OOOOOOOOh
Система
(2 Гбайт)
У Пользователь 2 У
4 (2 Гбайт) q
Система,
(2 Гбайт)
У Пользователь 3 У
4 (2 Гбайт) У
Система
Пользователь 1
Система
Пользователь 3
Свободно
Рис. 4-1. Виртуальная и физическая память
ВЫ VVIINUUVVb INI
Набор ресурсов
Кроме закрытого адресного пространства, с каждым процессом связан набор
разнообразных системных ресурсов. На рис. 4—2 показан типичный процесс
и его ресурсы.
Вверху схемы изображен маркер доступа процесса, описанный в гл. у.
“Диспетчер объектов и контроль доступа”. Обратите внимание, что маркер до-
ступа присоединяется к процессу непосредственно ОС. Если процессу требует-
ся получить информацию о его маркере доступа или, возможно, изменить не-
которые атрибуты маркера, то он должен открыть описатель своего объекта-
маркера. Подсистема защиты определяет, есть ли у процесса такое право. Про-
цесс, показанный на рисунке, не открыл описатель своего маркера доступа,
поэтому отсутствует стрелка, идущая из таблицы объектов к маркеру.
Ниже маркера доступа расположен набор структур данных, созданных
диспетчером виртуальной памяти для отслеживания виртуальных адресов, ис-
пользуемых процессом. Процесс нс может напрямую читать или изменять эти
структуры; диспетчер виртуальной памяти создает и модифицирует их неявно,
по мере выделения памяти программой. (Эти структуры данных более подроб-
но описаны в гл. 6, “Диспетчер виртуальной памяти”.)
Таблица объектов процесса показана в нижней части рисунка. Процесс
открыл описатели одного из своих потоков, файла и секции совместно ис-
пользуемой памяти. (Описание виртуального адресного пространства содер-
жит информацию о виртуальных адресах, занятых стеком потока и объектом-
секцией, на что указывают стрелки, идущие от описания виртуального адрес-
ного пространства к этим объектам.)
Кроме материально осязаемых ресурсов, показанных на рисунке, каждый
процесс имеет набор квот на ресурсы, ограничивающий объем памяти, кото-
рый его потоки могут использовать для открытия описателей объектов. Поми-
мо этого, у каждого процесса есть базовый приоритет и процессорное срод-
ство по умолчанию, описанные далее в этой главе.
Рис. 4-2. Процесс и его ресурсы.
Iлава 4. Процессы и потоки
4.1.3 Объект-процесс
В исполнительной системе NT процессы — это просто объекты, создаваемые
и уничтожаемые диспетчером объектов. Объект-процесс, как и другие объек-
ты, содержит заголовок, создаваемый и инициализируемый диспетчером
объектов. В заголовке хранятся стандартные атрибуты объекта, такие как дес-
криптор защиты объекта-процесса, имя процесса (может назначаться ему в
целях совместного использования) и каталог объектов, в котором хранится
имя, если оно есть.
Диспетчер процессов определяет атрибуты, хранящиеся в теле объектов-
процессов, а также предоставляет системные сервисы для чтения и изменения этих
атрибутов. Атрибуты и сервисы для объектов-процессов показаны на рис. 4-3.
Тип объекта
Процесс
Атрибуты тела объекта
Идентификатор процесса
Маркер доступа
Базовый приоритет
Процессорное сродство по умолчанию
Размеры квот
Время выполнения
Счетчик ввода-вывода
Счетчик операций виртуальной памяти
Порты исключений-отладки
Коды завершения
Сервисы
Создать процесс
Открыть процесс
Запросить информацию процесса
Установить информацию процесса
Текущий процесс
Завершить процесс
Выделить-освободить виртуальную память
Чтение-запись в виртуальную память
Защитить виртуальную память
Блокировать-разблокировать виртуальную память
Опросить виртуальную память
Сбросить виртуальную память на диск
Рис. 4-3. Объект-процесс.
Обратите внимание, что таблица объектов и описание адресного про-
странства нс показаны как часть объекта-процесса. Причина в том, что они,
хотя и связаны с процессом, но не могут быть изменены процессами
пользовательского режима напрямую. На рисунке изображены только тс
данные, которые код пользовательского режима может считывать или изме-
нять путем вызова сервисов объекта-процесса. В табл. 4-1 приведены атри-
буты объекта-npoi гссса.
Таблица 4-1. Атрибуты объекта - процесса
Атрибут Назначение
Идегит 1фт гкатор процесса Маркер доступа Уникальное значение, идентифицирующее процесс к ОС Объект исполнительной системы, содержащий информа- цию о правах зарегистрированного в системе пользователя, которого представляет данный процесс
Базовый приоритет Про| гессорное срод- ство по умолчанию Размеры квот Базовый приорите т потоков процесса Набор процессоров, на которых потоки процесса могут исполня ться по умолчанию Максимальный объем резидентной и нерезидентной систем- ной памяти, пространства в файле подкачки и процессорного времени, выделяемый нолыгоиательскому процессу
Время выполнения Счетчики ввода-вывода Счетчики onepai ц iii виртуальной памяти Порты исключений отладки Общее время выполнения всех потоков процесса Переменные, в которых записывается число и тип опера- ций ввода-вывода, выполненных потоками процесса Переменные, в которых записывается число и тин операций виртуальной памяти, выполненных потоками процесса Каналы коммуникаций между процессами, по которым диспетчер процессов посылает сообщение, если один из потоков процесса вызывает исключение
Код завершения Причина завершения процесса
Некоторые атрибуты объекта—процесса налагают ограничения па пото-
ки, исполняемые внутри процесса. Например, на многопроцессорном компью-
тере процессорное сродство может ограничить исполнение потоков процесса
подмножеством всех доступных процессоров. Аналогично, размеры квот регу-
лируют, сколько памяти, пространства файла подкачки и времени процессора
могут использовать все потоки процесса вместе.
Базовый приоритет процесса помогает ядру NT регулировать приоритет
потоков в системе. Приоритеты отдельных потоков изменяются, но всегда <х
таются в диапазоне базовых приоритетов их процессов. Подсистемы среды
могут использовать базовый приоритет, чтобы повлиять на то, потоки какого
процесса будут выбраны ядром NT для исполнения в первую очередь. Напри-
мер, подсистема Win32 при помощи сервисов NT повышает базовый приори-
тет процесса выбранного пользователем приложения и понижает базовый
приоритет процессов фоновых приложений, давая интерактивным приложе-
ниям преимущество над другими (см. разд. 4.2.3.) Размеры квот, процессорное
сродство и базовый приоритет входят в состав тех атрибутов и структур дан-
ных процесса, которые могут наследоваться от него другим процессом. Насле-
дование процессов описано в разд. 4.З.2.1.
Порты исключений и отладки процесса — это каналы коммуникаций меж-
ду процессами, по которым ОС посылает сообщения, если один из потоков
процесса возбуждает исключение или сели идет отладка процесса. Поток дру-
гого процесса ожидает у' порта для приема сообгценггя и соответствуют!1*
действий. Например, поток подсистемы среды может “слушать” у порта исклю-
чений для перехвата ошибок ее клиентских процессов, а отладчик может перс
хватывать исключения, такие как отладочные точки останова. (Более подроб-
ную информацию об объектах—портах и подсистемах среды см. в гл. б,
“Windows и защищенные подсистемы”.)
Глава 4. Процессы и потоки
Назначение большинства сервисов объекта-процесса очевидно. Сервис
создания процесса гибок и даст возможность разным подсистемам создавать
процессы с разными начальными атрибутами. Сервис текущего процесса по-
зволяет процессу быстро получить собственный описатель, нс обращаясь к
диспетчеру объектов. Сервис завершения процесса останавливает исполнение
его потоков, закрывает все открытые описатели объектов и уничтожает вирту-
альное адресное пространство процесса.
Сервисы виртуальной памяти, показанные на рис. 4—2, на самом деле ре-
ализованы диспетчером виртуальной памяти, однако каждому из них необхо-
дим описатель процесса, чтобы указать, к виртуальной памяти какого процесса
будет осуществляться доступ. Операции с виртуальной памятью описаны в гл. 6,
“Диспетчер виртуальной памяти”.
4.2 Что такое поток?
Если тема потоков управления Вам знакома, то Вы, вероятно, встречали разные
определения этого термина, в том числе “сдигшца исполнения”, “отдельный
счетчик команд” или ‘"подлежащая планированию сущность внутри процесса”.
Хотя каждое из этих определений по сути своей правильно, ни одно из них не
является удовлетворительным. Что в точности подразумевается под “единицей
исполнения”? Просто нечто, исполняемое процессором?
В то время как процесс — это логическое представление работы, которую
должна выполнить ОС, поток отображает одну из. возможно, многих необхо-
димых подзадач. Предположим, к примеру, что пользователь запустил в окон-
ном режиме приложение для работы с базой данных. ОС представляет этот
вызов приложения как один процесс. Теперь предположим, что пользователь
запросил генерацию отчета по данным из базы и сохранение этого отчета в
файле — понятно, что это длительная операция. Пока идет выполнение опера-
ции, пользователь .может ввести новый запрос к базе данных. ОС представляет
каждый из запросов — генерацию отчета и новый запрос к базе - как отдель-
ные потоки внутри процесса приложения для работы с базой данных. Эти
потоки могут выполняться процессором независимо друг от друга, что позво-
ляет проводить обе операции в одно и то же время (параллельно). У ОС есть
удобный и эффективный способ предоставления потоков для достижения та-
кой параллельности. Подробнее об этом будет сказано ниже.
Основные составляющие потока в исполнительной системе NT таковы:
Уникальный идентификатор, называемый идентификатором клиента.
I Содержимое набора регистров, отображающее состояние процессора.
Два стека: один используется потоком при работе в пользовательском
режиме, а другой — в режиме ядра.
Собственная область памяти, предназначенная дня использования под-
системами, библиотеками периода выполнения и динамически под-
ключаемыми библиотеками (DLL).
Регистры, стек и собственная область памяти называются контекстом
(context) потока. Фактические данные, составляющие контекст потока, зависят
от типа процессора.
Поток находится в адресном пространстве процесса, используя его дл}]
хранения данных во время выполнения. Если в одном процессе есть нескольц,
потоков, то они совместно используют адресное пространство и все ресурсы
процесса, включая маркер доступа, базовый приорите т и описатели объектов 1;
таблице объектов процесса. Ядро NT направляет потоки на исполнение некц.
торому процессору. Таким образом, каждый процесс NT должен иметь 11()
меньшей мере один поток
Многозадачность и мультипроцессорная обработка
Процессор может выполнять не более одного потока одновременно. Однако
многозадачная (multitasking) ОС даст пользователям возможность исполнять
несколько программ, причем создается впечатление, будто все они исполняют,
ся одновременно. Это достигается следующим образом:
1. Поток исполняется до тех пор, пока его исполнение не будет прерва-
но или пока ему нс придется ждать освобождения некоторого ресурса.
2. Сохраняется контекст потока.
3. Загружается контекст другого потока.
4. Этот цикл повторяется до тех пор, пока есть потоки, ожидающие
выполнения.
11ереключение npoi icccopa с исполнег тя одного потока i ta исполнение дру-
гого называется переключением контекста (context switching). В Windows NT его
осуществляет ядро исполнительной системы.
Как показано на примере двух потоков па рис. 4—4, ОС поочередно вы-
полняет то один поток, то другой. В конце концов, каждый поток заканчивает
выполнение своей подзадачи и либо завершается, либо получает другую зада-
чу. Очень высокая скорость работы процессора обеспечивает иллюзию одно-
временного выполнения всех потоков.
Многозадачность увеличивает объем работы, выполняемый системой, по-
тому что большинство потоков не могут исполняться непрерывно. Периоди-
чески поток прекращает выполнение и ждет, например, пока медленное усг
Зовершение
Ввод-вывод иди простой--------
Исполнение
Рис. 4-4. Многозодочность.
ройство ввода—вывода завершит пересылку данных или пока другой поток
использует ресурс, необходимый первому. Благодаря многозадачности, пока
один поток ожидает, может выполняться другой поток, и время процессора нс
расходуется впустую.
Вытесняющая многозадачность (preemptive multitasking) — это разно-
видность многозадачности, при которой ОС не жцет, пока поток добровольно
предоставит процессор другим потокам. Вместо этого ОС прерывает поток,
после того как он выполнялся в течение заранее заданного периода времени,
так называемого кванта времени (time quantum), или когда готов к выполне-
нию поток с большим приоритетом (например, реагирующий на пользова-
тельский ввод). Вытеснение предотвращает монополизацию процессора од-
ним потоком и предоставляет другим потокам их законную долю процессор-
ного времени. Исполнительная система NT — это система с вытесняющей мно-
гозадачностью. как и ее основная среда Windows, подсистема Win32. В невытес-
няющих версиях Windows для MS-DOS, чтобы достичь многозадачности, поток
должен был добровольно передавать управление процессором. Плохие или
примитивные программы могли захватить процессор в ущерб другим прило-
жениям или всей системе.
Иногда двум потокам необходимо взаимодействовать друг с другом, что-
бы скоординировать свои действия для достижения общей цели. Например, в
компиляторе С одни поток может выполнять препроцессорную обработку
программы на С. а другой — принимать результаты работы первого и компи-
лировать их в объектный код. Этим двум потокам необходим способ обмена
данными друг с другом.
До второй половины 80-х годов в большинстве ОС программы могли
иметь только один поток управления1. (Фактически в большинстве ОС для обо-
значения исполняемой сущности использовалось слово процесс (process). По-
ток (thread) — достаточно новый термин.) Так как у калщого процесса было
отдельное адресное пространство, двум процессам для обмена данными друг
с другом нужны были либо область совместно используемой памяти, либо со-
вместно используемый файл. Для такого рода коммуникаций между процесса-
ми широко использовались (и используются) каналы (см. рис. 4 5).
Препроцессорная обработка и компиляция программы двумя процесса-
ми (каждый с одним потоком), очевидно, должна идти быстрее, чем в случае
Рис. 4-5. Компилятор, состоящий из двух процессов.
1 Дэйв Катлер. главный архитектор Windows NT, замечаем, что в VAX EI.N, (X, реального времени,
которую он и еще некоторые члены команды Windows NT написали для Digital Equipment Corporation.
пороки были еще в 1983 году.
ОВЫ WINDOWS NT
одного процесса, так как многозадачная ОС может попеременно исполнять то
поток препроцессора, то поток компилятора. Как только препроцессор поме,
стит что-нибудь в совместно используемый буфер, компилятор может начать
свою работу. Приложения, подобные этому, которые исполняются в двух или
более местах одновременно, называются нарсычельными приложениями (con-
current applications).
Параллельность полезна приложениям и на однопроцессорном компью-
тере, но еще более она важна на многопроцессорном. При наличии несколь-
ких процессоров препроцессор и компилятор из нашего примера могут ис-
полняться параллельно. Если параллельное приложение хорошо спроектиро-
вано и минимизирует конкуренцию за ресурсы между своими потоками, то иа
многопроцессорном компьютере оно может работать быстрее, чем на одно-
процессорном (сравните рис. 4-6 с рис. 4-4).
Операционной системой с мультипроцессорной обработкой (multipro-
cessing) называется такая ОС, которая специально спроектирована для работы
на компьютерах с более чем одним процессором. ОС с симметричной муль-
типроцессорной обработкой (symmetric multiprocessing, SMP), такая как
Windows NT, может выполнять на любом процессоре как код пользователя,
так и код ОС. Если число потоков превышает число процессоров, ОС S.MP
также поддерживает многозадачность, разделяя время каждого процессора
между всеми ожидающими потоками. (Дальнейшие сведения о планировании
потоков в Windows NT см. в гл. 7, “Ядро”).
Зовершение
Поток 1
Процессор 1
Процессор2
Поток 2
Сэкономленное
время
Зовершение
Сэкономленное
время
Время
Ввод-вывод или простой--------
Исполнение
Рис. 4-6. Мулыипроцессорноя обработке.
Многопоточность
Использование двух процессов для достижения параллельности нс всегда эф'
фектнвно. В некоторых системах UNIX, например, когда один процесс создаст
другой, система должна скопировать все содержимое адресного пространства
первого процесса в адресное пространство второго. Для большого адресной*
пространства эта операция занимает много времени. Более того, два процесса
должны установить канал обмена данными друг с другом. Не во всех ОС эн*
осуществляется быстро и легко. Windows NT решает проблему, создавая удоб-
ные механизмы совместного использования памяти. Это память “копирование"
1лава 4. Процессы и потоки
при модификации”, позволяющая избежать копирования всего адресного про-
странства из одного процесса в другой, а также оптимизированное для локаль-
ного использования средство передачи сообщений. (Первая возможность опи-
сана в гл. 6, “Диспетчер виртуальной памяти”, а вторая — механизм локального
вызова процедур (LPC) — в гл. 5, “Windows и защищенные подсистемы”).
Даже при наличии этих усовершенствований бывают ситуации, когда бо-
лее выгоден другой подход к достижению параллельности, а именно, многопо-
точный процесс (multithreaded process). Как говорилось ранее, термину7 ноток
(thread) отвечает перемещение процессора по командам программы; каждый
поток отображает отдельный счетчик команд. У многопоточного процесса име-
ется два или более потоков (и счетчиков команд), которые совместно использу-
ют одно и то же адресное пространство, описатели объектов и другие ресурсы.
Каждый процесс NT создается с одним потоком. При необходимости
программа может создать внутри процесса дополнительные потоки. Они час-
то используются для выполнения в программе асинхронных операций
(asynchronous operations), т. е. операций, которые могут иметь место в любое
время, безотносительно к основному течению программы. К этой категории
часто относятся операции ввода—вывода. Например, можно использовать по-
ток для периодического сохранения редактируемого документа или для опро-
са устройства пользовательского ввода, например мыши или клавиатуры. Ис-
пользуя один поток для выполнения основной программы и создав второй для
опроса устройства ввода, система может по отдельности выполнять обе опера-
ции на одном процессоре, так что будет иметь место многозадачность. На мно-
гопроцессорном компьютере эти два потока могут выполняться одновремен-
но, притом не требуя расходов на создание второго процесса и инициализа-
цию его адресного пространства.
Чтобы достичь параллелизма с использованием потоков, программа со-
здает два или несколько потоков в одном процессе. Многопоточный компиля-
тор изображен на рис. 4-7.
Многопоточные процессы добиваются параллельности и при этом не име-
ют недостатков, связанных с использованием двух процессов. Потоки требуют
меньших издержек и создаются быстрее, чем процессы (в связи с этим их иногда
называют “легковесными процессами”). Кроме того, поскольку вес потоки про
цесса используют одну и ту’ же намять, за исключением своих стеков и содержи-
мого регистров, нс требуется никакого особого механизма обмена данными. Один
поток просто записывает свои результаты в памя ть, а друтой считывает их. Ана-
логично, все ресурсы процесса (объекты) одинаково доступны веем его потокам.
Процесс компилятора
Рис. 4-7. Многопоточный компилятор.
Для выбора порядка, в котором исполняются потоки, ядро NT используем
схему, основанную на приоритетах. Потоки с большим приоритетом исполни,
ются прежде потоков с меньшим приоритетом, и ядро периодически изменяем
приоритет каждого потока, чтобы гарантировать выполнение их всех. Прило.
жение может позволить своим потокам выполняться на любом процессоре й
многопроцессорной машине или может ограничить их выполнение подмц0,
жеством процессоров.
Использование многопоточного процесса — идеальное решение для сер.
верного приложения (например защищенных подсистем Windows NT), котц.
рое принимает запросы от клиентов и выполняет по каждому запросу один ц
тот же код. Например, файл-сервер выполняет операции с файлами; он откры.
вает файлы, читает из них, пишет в них и закрывает их. Хотя каждый запрос
может требовать от сервера работы со своим файлом, программа сервера за-
гружается в память только один раз. Каждый приходящий запрос принимается
и обрабатывается отдельным потоком сервера, который выполняет необходи-
мую функцию. Все запросы клиентов обслуживаются параллельно. Иллюстра-
цией этого служит рис. 4—8.
На рисунке два клиентских процесса (каждый с одним потоком, изобра-
женным извилистой линией) используют средство передачи сообщения для
посылки сообщения серверному процессу. Имеется несколько серверных по-
токов для исполнения кода сервера и посылки ответа клиентам.
Обратите внимание, что написание многопоточного приложения требу-
ет особой тщательности, так как все потоки процесса имеют полный доступ к
его адресному пространству. Потоки могут случайно пересечься друг с другом,
выполняя чтение или запись в память не в том порядке.
Такого не происходит, если приложения используют для достижения па-
раллельности два процесса и взаимодействуют явным образом путем посылки
сообщений или через каналы. Один процесс не может случайно или намерен-
но повредить адресное пространство другого. Именно по этой причине защи-
щенные подсистемы Windows NT реализованы как отдельные серверные про-
цессы (и именно поэтому они называются “защищенными” подсистемами).
Клиентский процесс
Серверный процесс
Рис. 4-8. Многопоточный сервер.
глава 4.1 |роцессы и потоки
Каждая подсистема сохраняет контроль за своим адресным пространством, не
допуская вмешательства других подсистем или пользовательских процессов.
Внутри сервера, однако, выгодно применят ь большое число потоков, совмест-
но использующих одно адресное пространство и ресурсы.
Полезны бывают обе техники достижения параллельности, как с исполь-
зованием нескольких процессов, так и с использованием нескольких потоков.
Задачи приложения определяют структуру, наиболее выгодную в данном кон-
кретном случае.
Суммируя сказанное, приведем термины, относящиеся к реализации
процессов ОС:
Многозадачность. Совместное использование процессора потоками,
ожидающими выполнения, и создание иллюзии одновременного вы-
полнения всех потоков.
Мультипроцессорная обработка. Исполнение одного и того же кода ОС
как на однопроцессорных, так и на многопроцессорных компьютерах.
ОС с симметричной мультипроцессорной обработкой выполняет сис-
темный код и код пользователя на всех доступных процессорах.
Многопоточность. Поддержка нескольких потоков внутри одного
процесса.
ОС высокого уровня должна поддерживать все перечисленные возмож-
ности. И Windows NT это делает.
************************************************
Начиная с Windows NT версии 3-51* Service Pack 3 в систему была добавлена новая сущность — во-
локна (fibers). Волокном называется легкий поток, планировку7 которого осуществляет прило-
жение. С точки зрения перевода слово “волокно” надо рассматривать как некий канал (сравни: оп-
товолокно), который можно использовать для направления потока. В английском языке появление
термина fiber более понятно, так как thread дословно переводится как “нить” Нить, как известно,
состоит из волокон.
Волокна исполняются в контексте тех потоков, которые занимаются их планированием. Каж-
дый поток может управлять несколькими волокнами. В общем случае волокна не дают никаких
преимуществ в хорошо спроектированных многопоточных приложениях. Однако использова-
ние волокон может оказаться полезным при переносе приложений, разработанных в расчете
на планирование своих собственных потоков. Это могут быть приложения, написанные для
других платформ.
С точки зрения системы волокна подразумевают индивидуальность потоков, их породивших. Например
если волокно осуществляет доступ к локальной памяти потока, то это будет локальная память именно
того потока, кеггорый породил волокно. Если волокно вызывает функцию ExitThread, то закроется но-
ток. породивший это волокно.
С волокнами связан гораздо меньший объем информации о состоянии, чем с потоками. У воло-
кон поддерживается только их стек, подмножество регистров и данные, переданные при созда-
нии волокна.
Один поток может породить несколько волокон. Однако следует помнить, что одновременно в
потоке может исполняться только одно волокно, которое использует все ресурсы, выделенные
потоку. Волокно исполняется до тех пор, пока нс произойдет переключение на другое волокно
внутри потока или пока планировщик нс завершит исполнение потока, породившею волокно.
Объект-поток
Процесс NT остается безжизненным, пока у него пет потока, который можцц
направить на выполнение. Если у процесса есть поток, последний может сц.
здать дополнительные потоки.
Как и процессы, потоки исполнительной системы NT реализованы в виде
объектов, создаваемых и уничтожаемых диспетчером объектов. Диспетчер
процессов определяет тело объекта-потока и сервисы, используемые для ра.
боты с потоками после их создания. Объект-поток изображен на рис. 4—9,
Тип объекта
Поток
Атрибуты тела объекта
Клиентский идентификатор
Контекст потока
Динамический приоритет
Базовый приоритет
Процессорное сродство потока
Время выполнения потока
Состояние тревоги
Счетчик приостановок
Маркер имперсонации
Порт завершения
Код завершения потока
Сервисы
Рис. 4-9. Объект-поток.
Создать поток
Открыть поток
Запросить информацию потока
Установить информацию потока
Текущий поток
Завершить поток
Запросить контекст
Установить контекст
Приостановить
Возобновить исполнение
Тревога потока
Проверить состояние тревоги потока
Зарегистрировать порт завершения
В табл. 4—2 описаны атрибуты потока.
Как можно заметить, некоторые атрибуты потока напоминают атрибут'J
объекта. Одни атрибуты, такие как процессорное сродство потока и динам'1'
ческий приоритет, фактически усиливают или ослабляют ограничения, зада"'
пыс для процесса в целом. Например, процессорное сродство каждого потока
— это неполное подмножество (равно или меньше) процессорного сродства
процесса. Следовательно, можно заставить разные потоки процесса выпо-'1'
няться на разных группах процессоров.
। Л,
Таблица 4-2. Атрибуты объектснпотоко
Атрибут Нозночение
Иды m 1ф> 1 катор клиента Контекст потока Уникальное значение, идентифицирующее поток при вызове им сервера Набор значений регистров и других непостоянных данных, определяющих состояние выполнения потока
Динамический приоритет Базовый Приоритет- Процессор! юе сродство потока Приоритет потока на данный момент Нижний предел динамического приоритета потока Набор процессоров, на которых может исполняться поток, (неполное) подмножество процессорного сродства процесса потока
Время выполнения потока Статус оповеще! ц 1Я Общее время выполнения потока в пользовательском режиме и режиме ядра Флаг, указывающий на необходимость отработки потоком асинхронного вызова процедуры (АРС)
Счетчик приостановок Маркер имперсонации Количество приостановок выполнения потока без последующего возобновли н 1я Временный маркер доступа, позволяющий потоку выполнять действия от имени другого процесса (используется подсистемами)
Порт заперши и 1Я Канал коммуникации между процессами, в который диспетчер процессов посылает сообщение при завершении потока (используется подсистемами)
Код завершения потока Причина завершения потока
Аналогично, каждый поток имеет базовый уровень приоритета, который
лежит в диапазоне от двух уровней ниже базового приоритета процесса до
двух уровней выше этого приоритета, как показано на рис. 4—10.
На этом рисунке показан также динамический приоритет потока, нижней
границей которого является базовый приоритет потока, а верхняя зависит от
вида работ, исполняемых потоком. Например, если поток обрабатывает поль-
зовательский ввод, то ядро NT поднимает его динамический приоритет; если
же он выполняет вычисления, то ядро постепенно снижает его приоритет до
базового. Снижая приоритет одного процесса и поднимая приоритет другого,
подсистемы могут управлять относительной приоритетностью потоков внут-
ри процесса. Базовый приоритет процесса определяет, сколь сильно могут
различаться приоритеты потоков процесса и как они соотносятся с приорите-
тами потоков других процессов.
Как и приоритеты, другие атрибуты объекта потока предназначены для
того, чтобы предоставить ОС (и в частности, подсистемам среды) возмож-
ность управления созданным ею потоком. Например, контекст потока содер-
жит все, что нужно ОС для возобновления исполнения прерванного потока: а
именно, содержимое регистров процессора и стеков пользователя и ядра. При-
остановив поток, изменив его контекст и запустив поток снова, подсистема
среды может изменить его поведение или начать его выполнение с адреса,
отличного от точки останова. (Этот способ могут также использовать отлад-
чики пользовательского режима для управления выполнением потоков.)
15
14
13
12
11
10
9
8
Приоритет -j
6
5
4------► Базовый приоритет процесса
3
2
1
0___________________________________
Управляется Приложением
Рис. 4-10. Соотношение приоритетов’.
Базовый
приоритет
потока
Динамический
приоритет
потока
Приложением Исполнительной
системой МТ
Другой сервис, предоставляемый объектам-потокам, — посылка потоку
оповещений — это средство, позволяющее подсистемам среды или другим ча-
стям ОС асинхронно уведомлять поток о необходимости выполнения им за-
данной процедуры. Поток, предполагающий, что может быть получено опо-
вещение, может вызвать сервис для проверки его наличия (см. разд. 4.2.5).
Порт завершения потока похож на порт исключений и отладки процесса.
Он позволяет подсистеме среды получать уведомление о завершении потока
одного из ее клиентских процессов. При получении такого уведомления под-
система может обновить поддерживаемую ею информацию о потоке или про-
цессе, в котором он находится.
Сервис текущего потока позволяет потоку быстро получить собственный
описатель, не открывая его в явном виде. Этот описатель может использовать-
ся, например, для получения потоком информации о себе, такой как общее
время выполнения, текущий приоритет и процессорное сродство.
Идущие далее разделы содержат более подробную информацию о сер-
висах процессов и потоков. В следующей главе описаны защищенные подси-
стемы Windows NT.
Синхронизация
При работе параллельного приложения его потокам часто требуется способ
связи друг с другом для координации своих действий. Пример такой связи —
передача данных через каналы. Однако простейшей формой связи является
синхронизация (synchronization). Синхронизация озггачает способность пото-
ка добровольно приостанавливать свое исполнение и ожидать, пока нс завер-
шится выполнение некоторой операции другим потоком.
’ На рисунке показаны только потоки переменною приоритета, которые выполняю гея на урок
не приоритета от О до 15. Потоки реального времени исполняются на уровнях приоритета <л
16 до 31. Подробнее см. ел. 7. “Ядро”-
I лови 4i. । цэоцессы и потоки
В приведенном выше примере с компилятором препроцессор считывает
исходный код на С и помещает результаты его обработки в буфер памяти,
который он использует совместно с компилятором. Последний принимает ре-
зультаты препроцессора в качестве исходных данных, выполняет компиляцию
и генерирует объектный код. После запуска программы поток компилятора
должен ждать, пока поток препроцессора поместит что-либо в буфер, и лишь
затем читать данные. Аналогично, когда весь буфер заполнен, препроцессор
должен ждать, пока компилятор не выберет данные из буфера, прежде чем
записывать туда новую информацию.
Все ОС, поддерживающие многозадачность или мультипроцессорную
обработку7, должны предоставлять потокам способ ожидания того, что другой
поток что-либо сделает: например, освободит накопитель на магнитной ленте
или закончит запись в совместно используемый буфер памяти. ОС должна так-
же дать потоку возможность сообщить другим потокам об окончании выпол-
нения операции. Получив такое уведомление, ожидающий поток может про-
должить выполнение.
Средства ожидания и сообщения реализованы в исполнительной систе-
ме NT как часть объектной архитектуры. Синхронизационные объекты
(synchronization objects) — это объекты исполнительной системы, при помо-
щи которых поток синхронизирует свое выполнение. К их числу относятся
следующие объекты:
Процесс
Поток
® Файл
Событие
Пара событий
В Семафор
Таймер
Мутант*
Первые три из перечисленных выше объектов выполняют и другие функ-
ции, в то время как последние пять существуют исключительно для поддержки
синхронизации. При помощи этих объектов исполнительной системы потоки
могут координировать свое выполнение с разнообразными происшествиями в
системе, используя различные правила для различных ситуаций.
В любой момент времени синхронизационный объект находится в одном
из двух состояний: свободен (signaled state) либо занят (nonsignaled state).
Состояние “свободен” определено по-разному для разных объектов. Объект-
поток находится в состоянии “занят” все время существования, но устанавлива-
' В Windows NT версии 4.0 добавлен новый синхронизационный объект — ожидающий таймер
(waitable timer). Как и у других синхронизационных объектов, у ожидающего таймера есть они
сатель и имя. Описатель ожидающего таймера может быть передан функциям (например. Wait
ForMultipleObjccts). Дня этого объекта можно установить временной интервал, выбрать однократ-
ное или неоднократное срабатывание, а также передать указатель па функцию, вызываемую при
переходе таймера в состояние “свободен”. По истечении указанного промежутка времени ожида-
ющий таймер устанавливается в состояние “свободен”.
с гея системой в состояние “свободен”, когда его выполнение завершается. Airj.
логично, ядро устанавливает процесс в состояние “свободен”, когда завершает,
ся его последний поток. В противоположность этому, объект—таймер “срабц.
тывает” через заданное время (по истечении этого времени ядро усганавливае|
объект—таймер в состояние “свободен”).
Для синхронизации с объектом поток вызывает один из системных сер.
висов ожидания, предоставляемых диспетчером объектов, и передает описа-
тель данного объекта. Поток может ждать один или несколько объектов, а так-
же задат ь отмену ожидания, если оно не закончилось за некоторый промежу.
ток времени. Всякий раз, когда ядро устанавливает объект в состояние “свобо-
ден”, оно проверяет, есть ли потоки, ожидающие этот объект. Если такие пело-
ки есть, то ядро выводит один или несколько из них из состояния ожидания
и они могут продолжить выполнение.
При выборе механизма синхронизации следует учитывать правила, уп-
равляющие поведением различных синхронизационных объектов. Закончится
ли ожидание потока, когда объект, у которого он ждет, будет переведен в со-
стояние “свободен”, зависит от типа объекта, как показано в табл. 4-3-
Таблица 4-3. Определения состояния "свободен"
Тип объекта Усгановливоется в состояние "свободен", когдо: Кок влияет но ожидоющие потоки:
Процесс завершается последний поток псе освобождаются
Поток завершается исполнение потока ’го же
Файл завершается операция ввода—вывода «
Событие поток устанавливает событие
Пара событий выделенный поток клиента или сервера устанавливает событие освобождается другой выделенный поток
Ссма<]>ор счетчик семафора доходит до пуля нее освобождаются
Таймер наступает заданное время или истекает временной интервал то же
Мутант поток освобождает мутант освобождается один ноток
В большинстве случаев, когда объект устанавливается в состояние “сво-
боден”, все ожидающие потоки немедленно освобождаются. Например,
объект-событие используется для оповещения о том, что произошло некото-
рое событие. Когда объект-событие устававливается в состояние "свободен' -
все ожидающие его потоки освобождаются. Исключением является почоК-
ожидающий одновременно более одного объекта; такому потоку, возможно,
потребуется продолжать ожидание до тех пор, пока и остальные объекты «к’
станут свободными.
В отличие от объекта-события, для объекта мутанта (для программно к
в Win32 огг видим как объект -мьютекс) определено понятие владения и"-
Объект-мутант применяется, чтобы установить взаимоисключающий доступ к
ресурсу, и в данный момент времени владеть им может нс более одного гют< >к;>-
Когда мугат освобождается, ядро устанавливает его в состояние “свободен •
пекле чего выбирает для исполнения один из потоков, ожидающих сто. Поток-
выбраггный ядром, завладевает мутантом, а все остальные потоки продолжаю’1
ждать (см. гл. 7, “Ядро”, где синхронизация описана более детально).
Семантика синхронизации исполнительной системы NT видима про-
граммистам Win32 посредством функций API WaitForSingleObjcctQ и WaitFor-
MultipleObjectsQ, которые реализованы при помощи вызовов аналогичных си-
стемных сервисов диспетчера объектов NT. Поток в приложении Win32 может
синхронизироваться с такими объектами Win32, как процесс, поток, событие,
семафор, мьютекс или файл. В качестве примера рассмотрим синхронизацию
потока в программе электронной таблицы с другим потоком этой программы.
Предположим, что у приложения есть основной поток, выполняющий обыч-
ные функции работы с электронной таблицей, и вспомогательный поток, вы-
водящий файлы электронной таблицы на принтер. Теперь допустим, что
пользователь отправляет электронную таблицу на печать и. прежде чем печать
завершится, вводит команду выхода из программы. Основной поток, который
получает запрос на выход из программы, не завершает процесс немедленно
(хотя он может убрать окно программы с экрана). Вместо этого он вызывает
функцию WaitForSingleObjcctQ, чтобы подождать, пока поток спулера нс за-
кончит печать и не завершится. После завершения потока спулера основной
поток освобождается и завершается, что приводит к выходу из программы
электронной таблицы и завершению соответствующего процесса.
4.2.5 Оповещения и асинхронные вызовы процедур
В некоторых ситуациях полезно позволить одному потоку* асинхронно уве-
домлять другой поток о необходимости остановить выполнение. Эта операция
называется в исполнительной системе NT оповещением (alert) и тесно связана
с синхронизацией. Представьте себе приложение базы данных, обрабатываю-
щее запрос. Приложению неизвестно, находятся ли необходимые данные на
локальном или на удаленном компьютере. На всякий случай приложение запус-
кает два потока; один ищет данные локально, второй — по сети. Как только
один из потоков найдет данные, он посылает оповещение другому потоку. В
ответ па это оповещенный поток прекращает выполнение текущей операции
и возвращается к исходному состоянию, готовый к выполнению новой задачи.
Оповещения не слишком широко применяются в Windows NT, помимо
тех случаев, когда они используются в комбинации с другим механизмом
асинхронного уведомления — асинхронным вызовам процедур (asynchronous
procedure call, АРС). Время от времени ОС требуется уведомлять поток о том.
что он должен выполнить некоторое действие. Иногда поток должен выпол-
нить определенное действие после того, как произошло некоторое событие.
Например, пользователь может захотеть, чтобы Windows послала ему сообще-
ние с напоминанием о времени запланированной встречи. В Windows NT этот
тип асинхронного уведомления реализуется с применением АРС пользователь-
ского режима. Это означает, что подсистема Win32 обращается к исполнитель-
ной системе NT для установки таймера и передаст указатель на процедуру
(АРС), которая будет посылать сообщение пользователю. Когда таймер сраба-
тывает, исполнительная система NT напоминает потоку подсистемы Win32 о
необходимости выполнения заданной процедуры АРС. После ее выполнения
поток Win32 продолжает выполнять то, чем был занят раньше.
Хотя некоторые асинхронные операции тенерируютея программами
пользовательского режима, большинство из них генерируются ОС и особенно
системой ввода-вывода NT. Последняя является асинхронной, т. с. вызываю-
щий поток может запустить операцию ввода-вывода, а потом заниматься дру
гимн делами, пока устройство ввода-вывода выполняет ее. Когда оно законны
передачу данных, система ввода-вывода должна приостановить вызывающ,^
поток и скопировать результаты операции ввода-вывода в его адресное iij)(
странство. Ддя этого система ввода-вывода использует АРС режима ядра.
АРС пользовательского режима и режима ядра имеют ряд различий. н
одно из них особенно важно. АРС режима ядра может в любой момент гтре
рвать исполнение потока пользовательского режима и заставить его выгюп
нить заданную процедуру. Обычно это происходит без ведома приложен^
Генерируется программное прерывание, и, как и в случае аппаратного прсрЬ|.
вания, система просто на короткое время “крадет” поток приложения и застав,
ляет его выполнить процедуру АРС. В противоположность этому; АРС пользе-
вательского режима может быть доставлен только в определенные точки, когда
запросивший его поток готов к исполнению АРС.
NT предоставляет потоку два способа регулировки того, в какой момент
он получит асинхронное уведомление пользовательского режима (оповеще-
ние или АРС пользовательского режима). Поток может либо вызвать базовый
сервис, чтобы проверить, было ли ему послано оповещение, либо ждать v
описателя объекта, разрешив прерывание этого ожидания оповещением, в
обоих случаях, если имеется ожидающий АРС для данного потока, ядро NT
доставляет его, и поток выполняет заданную процедуру. После этого ядро во-
зобновляет исполнение потока в той точке, где он был прерван.
Доступ к оповещениям и АРС в API Win32 (только для NT) осуществляется
через расширенные функции ввода—вывода. Расширенные функции ReadFile-
Ех() и WriteFileExQ позволяют потоку выполнять чтение и запись файла асин-
хронно, предоставив процедуру АРС, которую поток будет выполнять после
завершения операции ввода-вывода. Функции WaitForSingleObjectEx и WaitFor-
MultipleObjectsEx позволяют потоку ожидать в оповещенном состоянии в неко-
торой точке после выдачи запроса ввода—вывода. Подсистема POSIX не предо-
ставляет возможностей АРС для приложений POSIX, но использует АРС режима
ядра для эмуляции доставки сигналов POSIX. Аналогично, будущие подсистемы
среды смогут использовать АРС для реализации других средств асинхронного
уведомления. Мы вновь вернемся к теме АРС при обсуждении ядра NT, которое
управляет обработкой АРС, и системы ввода—вывода NT, которая интенсивно
их использует.
Структура процессов
Процессы — это динамические сущности, создаваемые и уничтожаемые пр»
работе ОС. Один процесс создает другой, который, в свою очередь, также
может создавать процессы. Структура процессов (process structure) определЯ'
ет, каким образом ОС создает, использует и уничтожает процессы и потоки »
какие отношения существуют между данным процессом и другими процессам1’
Программисты, пишущие приложения Win32, MS-DOS, OS/2 или POSI^-
никогда пс имеют дела с базовыми процессами и потоками NT. Win32 и друг1,с
подсистемы изолируют программиста от них, создавая собственные среды. ”
которых программист Win32 видит только процессы Win32, программист
POSIX — только процессы POSIX и т. д. Однако, в первую очередь благодаря
нижележащим средствам структуры процессов исполнительной системы NT,
эти непохожие среды и могут сосуществовать в одной ОС.
В следующем разделе рассматриваются некоторые требования различ-
ных подсистем среды. Затем идет раздел, описывающий механизмы, которые
диспетчер процессов NT предоставляет подсистемам.
д3.1 Требования подсистем среды
Одной из основных задач подсистемы среды Windows NT является эмуляция
API, для которого написаны ее клиентские приложения (например, API Win32
или POSIX). Другая ее основная функция — реализация структуры процессов,
требуемой этими клиентами. Марк Люковски и Стив Вуд, разработавшие для
Windows NT подсистемы сред POSIX и OS/2, тщательно проанализировали, что
может потребоваться этим и будущим подсистемам среды для эмуляции соот-
ветствующих API. Они выделили следующие (относящиеся к процессам) сред-
ства, необходимые для типичной среды:
Создание и завершение процессов и потоков.
Протоколирование и поддержка взаимоотношений между процессами.
Выполнение операций (как локальных, так и сетевых) от имени клиент-
ского процесса.
Чтение из, запись в и другие манипуляции с адресным пространством
клиентского процесса.
Остановка клиентского потока, возможно, изменение его контекста и
запуск вновь.
Перехват и обработка исключений, генерируемых клиентскими
процессами.
Создание процесса, стоящее первым пунктом в списке, — это самая обыч-
ная операция для подсистемы, и она хорошо иллюстрирует использование
подсистемами среды базовых сервисов процесса для выполнения своих задач.
На рис. 4—11 показано, как соотносятся создание процесса из прикладной
программы и создание процесса исполнительной системы NT.
Клиентское приложение, в- данном примере приложение Win32, POSIX
или OS/2, создает процесс с помощью соответствующих API своей среды. За-
прос на создание процесса передается через средство передачи сообщений
исполнительной системы NT (описано в гл. 5, “Windows и защищенные подси
стемы”) соответствующему серверу, который обращается к диспетчеру процес-
сов NT для создания базового процесса.
После создания базового процесса NT диспетчер процессов возвращает
описатель объекта—процесса. Подсистемы среды принимают этот описатель и
создают подходящие возвращаемые значения для клиентских приложений. На
рис. 4-12 показано, что именно возвращают различные подсистемы.
Обратите внимание, что между получением описателя от диспетчера
процессов и возвратом результата клиентскому приложению подсистема сре-
ды должна проделать некоторую дополнительную работу. В частности, подси
стемы снова обращаются к диспетчеру' процессов, чтобы создать поток для
нового процесса.
WINDOWS NT
Iaobq 4. Процессы и потоки
процесс ПТ
процесс NT
Клиентские
процессы
Серверные
процессы
процесс NT
Системные сервисы
Диспетчер
памяти
Диспетчер
процессов
Режим ядра
Средство
локального
вызова
процедур
Пользовательски^
режим
-----J . 1Ч1Л. 1 > I--
Созд-1 >ь объект-процесс
Диспетчер |ОЯМИЯ№
объектов । митор
лциты
Диспетчер
, —ОДО ВЫЬОДС
Файловые системы
Диспетчер wmd |
Драйверы устройств]
Рис. 4-11. Создание процесса.
' Новый
ч процесс /
Возврат описателя
Возврат описателя Возврат описателя
Как показано на рис. 4—12, разные среды ОС возвращают при создании
процесса разные результаты. Кроме того, ОС различаются принятыми в них
правилами и соглашениями по управлению процессами. Одно из фундамен-
тальных различий между' поддерживаемыми в Windows NT средами ОС связано
с тем, поддерживают ли они многопоточные процессы. Win32 и OS/2, напри-
мер, допускают многопоточные процессы, тогда как POSIX, MS-DOS и 16-раз-
рядная Windows — нет.
Подсистемы среды различаются и тем, какие существуют в них отношения
между7 процессами. Например, POSIX и OS/2 объединяют свои процессы в иерар-
хии, или деревья процессов (process trees). И та и друтая создают начальный про-
цесс, который порождает так называемые дочерние процессы (child process). До-
черний процесс, в свою очередь, может создать собственные дочерние npoi iccci>t
Все процессы, кроме начального, имеют родителя, от которого наследуют неко-
торые ресурсы и характеристики. Эти соотношения показаны на рис. 4—13-
Как POSIX, так и OS/2 используют соотношения между клиентскими про-
цессами для управления последними. Например, при завершении процесса
POSIX или OS/2 система завершает нес его дочерние процессы. Более той’-
совместимая с POSIX ОС поддерживает другие типы соотношений между про-
цессами, включая группы процессов (process groups) — объединения взаимосвя-
занных процессов и сессии (sessions) — объединения групп процессов. Для сес-
сий и групп процессов системы POSIX обеспечивается детализированная се-
мантика управления процессами, не имеющая точных эквивалентов в других ОС.
Исполнительная система NT должна обеспечить подсистеме среды возможность
поддержки любых необходимых ей соотношений между7 процессами.
Рис. 4-13. Иерархия процессов в POSIX и OS/2.
Помимо различий в группировании процессов и в поддержке многопц.
точности, подсистемы среды различаются правилами создания новых процсс-
сов. В табл. 4-4 показаны некоторые различия между структурами процессов
для трех сред ОС, поддерживаемых Windows NT.
Таблица 4-4. Семантика создания процессов
Windows (32-разрядная) POSIX OS/2 "
Функция API CreateProcess() fork() DosExecPgm()
Иерархия Не поддерживает Новый процесс Новый процесс со-
процессов формального соотно- шения родитель-по- томок создается как по- томоквызываю- щего процесса здается как пото- мок вызывающею процесса
Наследование Копирует для дочер- него процесса все опи- сатели объектов, от- крытые с атрибутом наследования Копирует для по- томка файловые дескрипторы родителя Копирует для по- томка все описате- ли файлов, каналов и семафоров роди- теля, которые были открыты с правами наследования
Инициализация 11нициализируег Инициализирует Инициализирует
адресного адресное простран- адресное простран- адресное простран-
пространства ство процесса испол- няемой программой ство потомка, копи- руя адресное прост- ранство родителя ство потомка ИСПОЛНЯСлМОЙ программой
Идентифика- Возвращает описатель Возвращает иденти- Возвращает иденти-
ция процесса нового процесса фикатор процесса нового потомка фикатор процесса нового потомка (если потомок выполняется асинхронно)
Потоки Создает один поток и поддерживает МНОГОПОТОЧ1 юсть Создает один поток, но не поддерживает МНОГОПОТОЧ1 юсть Создает один поток и поддерживает многопоточность
Как можно видеть, иерархии процессов, инициализация адресного про-
странства и идентификация процессов различны в разных средах. Хотя неко-
торые различия кажутся небольшими, диспетчер процессов должен поддержи-
вать все среды одинаково хорошо и обеспечить существование различных
структур процессов без конфликтов между’ ними. В следующем разделе описа-
но, как это дост игается.
Базовая структура процессов
При проектировании базовой структуры процессов разработчики быстро по-
няли, что поддержка нескольких типов структуры процессов в базовой О(-
даже если бы она была возможна, привела бы к созданию крайне сложной 11
хаотичной системы. По счастью, большинство деталей, относящихся к структу-
ре процессов, пс являются фундаментальными для функционирования нижеле-
жащей ОС. Структуры процессов могут быть реализованы подсистемами сре-
ды, работающими в пользовательском режиме за пределами исполнительно"
системы NT. Чтобы обеспечить такую возможность, структура процессов ис-
полнительной системы NT не устанавливает жестко каких-либо правил, кото-
рые могли бы помешать реализации другого набора правил. Вместо этого пре-
доставляется базовый набор механизмов, который подсистемы могут исполь-
зовать как основу для реализации собственных структур процессов. Как при-
мер такого подхода, в табл. 4—5 представлены гибкие правила создания про-
цесса исполнительной системы NT.
Исполнительная система NT рассматривает создание процесса как созда-
ние объекта, и не более того. Когда диспетчер процессов заканчивает создание
процесса, он возвращает подсистеме среды описатель нового процесса. Под-
система отвечает за вызов диспетчера процессов для создания потока в новом
процессе.
Таблица 4-5. Семантика создания базового процесса NT
NT
Функция API N tCreateProcess()
Иерархия Создает новый процесс, независимый от вызывающего процесса,
процессов и возвращает описатель объекта
Наследование Вызывающий задает родителя, от которого новый процесс насле- дует описаа ели объектов, открытые с атрибутом наследования
Инициализация Инициализирует адресное пространство нового процесса
адресного исполняемой программой или как копию адресного пространства
пространства родителя
Идентификация процесса Возвращает описатель объек та NT для нового процесса
Потоки Не создает поток в новом процессе автоматически, но поддер- живает многопоточность
Диспетчер процессов NT не запоминает информацию о том, каким про-
цессом создан новый процесс. Поэтому для эмуляции соотношений между’ про-
цессами, необходимых приложениям, каждая подсистема среды поддерживает
записи о созданных ею клиентских процессах и соотношениях между ними. В
следующих разделах описаны некоторые средства, предоставляемые исполни-
। тельной системой NT подсистемам среды для управления их клиентами.
4-3.2.1 Управление клиентскими процессами
Для запуска базового процесса NT нужно не только создать поток, но и предо-
ставить минимальный набор ресурсов. Если снова обратиться к рис. 4—2, то
можно видеть, что у процесса есть маркер доступа, свое содержимое адресно-
го пространства и свои описатели объектов. Эти ресурсы, а также квоты про-
цесса и друтие параметры полностью или частично наследуются от другого
процесса — “родительского”. Термин “родительский процесс” взят в кавычки
из-за принятого в исполнительной системе NT уникального понятия назнача-
емого родителя. Рассмотрим схему, показанную на рис. 4—14.
На рисунке приложение POSIX вызывает подсистему POSIX для создания
нового процесса POSIX. Подсистема (являющаяся также процессом) вызывает
i исполнительную систему NT, чтобы создать базовый процесс. Так как нодсис-
I тема POSIX выступает от лица клиентского приложения, то новый процесс
должен наследовать ресурсы нс от подсистемы, а от ее клиента. То же самое
верно и для создания процесса приложением Win32 и OS/2. Чтобы подсистемы
Приложение
POSIX
Рис. 4-14. Нозночение родительского процессе.
среды могли эмулировать семантику наследования процессов, необходимую
их приложениям, в исполнительной системе NT имеется сервис процесса, ко-
торый позволяет вызывающему (в данном случае, подсистеме) по желанию
задать родителя нового процесса.
Новый базовый процесс NT наследует от родительского процесса маркер
доступа, размеры квот, базовый приоритет и процессорное сродство по умол-
чанию. Он наследует и все описатели из родительской таблицы объектов, от-
крытые с признаком наследования. Адресное пространство процесса также
может наследоваться, если это нужно подсистеме. Подсистема POSIX использу-
ет эту возможность для эмуляции функции API POSIX fork(), тогда как подсис-
темы Win32 и OS/2 задают исполняемую программу, подлежащую загрузке
адресное пространство нового процесса.
Прежде чем новый процесс начнет выполняться, ему’ должен быть придан
поток Для приложений Win32 и OS/2 создание потока нс рассматривается как
эпсрация, отдельная от создания нового процесса. Приложения Win32 и OS 2
предполагают, что, когда функция создания процесса возвращает им управление,
поток уже создан. Однако в NT поток не создается автоматически, поэтому нод-
лпстсмы среды должны снова вызвать диспетчер процессов для создания потока
i новом процессе. Создавая поток, диспетчер процессов позволяет подсистемам
казать процесс, которому7 будет принадлежать новый поток Это дает возмож-
гость, например, подсистеме W in32 создать процесс для одного из своих кчнен-
ов, после чего поместить поток в адресное пространство этого клиента. Новый
юток начинает исполняться с базовым приоритетом клиентского процесса, на
аборе процессоров, заданных в процессорном сродстве клиентского процесса.
। с ограничениями, установленными маркером доступа клиентского процесса.
Глава 4. Процессы и потоки
Помимо создания процессов и потоков от лица других процессов, дис-
петчер процессов NT предоставляет средства, позволяющие подсистеме при-
соединяться к адресному пространству клиента и производить его чтение или
запись в него, выделять и освобождать виртуальную память клиента, а также
приостанавливать выполнение клиентских потоков, изменять их контексты и
снова запускать. Подсистема также может дублировать описатели из собствен-
ной таблицы объектов в таблицу объектов клиента. Более того, она может за-
вершать клиентские потоки или клиентский процесс.
Эти мощные возможности дают подсистемам пользовательского режима
такие средства управления, которые в болыпинсгве ОС имеются только у кода
ОС в режиме ядра. Подсистемы среды получают свободу управлять своими
клиентскими приложениями и создавать для них среду ОС, которая отличается
от базовой среды исполнительной системы NT.
4.3.2.2 Как предотвратить неправильное использование
Создание процессов и потоков от лица другого процесса, чтение и запись в
виртуальную память другого процесса и управление потоками другого про-
цесса — это операции, которые нельзя использовать беспорядочно. Чтобы
предотвратить их неправильное использование, система защиты Windows NT
(конкретно, се механизмы защиты объектов) гарантирует, что такие операции
будут тщательно контролироваться.
Подсистемы среды Windows NT в своей основе — это просто обычные
процессы. Подобно другим процессам, они определяют, какие права доступа
предоставляются создаваемым ими процессам. Поскольку практически все
процессы пользовательского режима создаются подсистемами среды, эти под-
системы управляют поведением всех пользовательских процессов в системе.
Например, при создании клиентского процесса подсистема отказывает
ему’ в возможности обойти ее и завершиться вызовом базового сервиса NT. В
противном случае процесс мог бы оставить глобальные структуры данных
подсистемы в неактуальном состоянии, возможно, повредив другим процес-
сам, выполняющимся под ее управлением. Подсистема предотвращает это, не
предоставляя новому процессу’ прав на удаление его собственного объекта-
процесса в списке контроля доступа (ACL) этого объекта (см. гл. 3, “Диспетчер
объектов и контроль доступа”)- Нс имея прав на удаление, процесс никогда нс
сможет открыть собственный описатель, который позволил бы ему завершить-
ся. Система защиты не позволит сервису завершения успешно выполниться,
если ему' не передан правильный описатель.
Благодаря системе защиты объектов клиент не может получить какую-
либо возможность, если она нс предоставлена ему явно подсистемой. Таким
образом, проектировщику' подсистемы нс надо держать в голове все те неза-
конные действия, которые может предпринять клиентский процесс, и изобре-
тать средства их предотвращения. Вместо этого достаточно определить, что
процесс должен быть способен делать, и предоставить ему соответствующие
возможности. В болыпинсгве случаев это означает, что ни один из обычных
процессов пользовательского режима не може т вызывать базовые сервисы NT.
Процесс пользовательского режима может вызывать лишь функции API, предо-
ставленные создавшей его подсистемой.
Тс же самые механизмы нс дают пользовательским процессам завершать
другие процессы или манипулировать ими. Для доступа к другим процессам
WINDOWS NT
процесс может вызывать только те функции API, которые доступны в его среде
(Win32 или POSIX, например). Более того, способность процесса вызывап,
даже эти сервисы ограничена его правами доступа к базовым объектам, кото,
рые будут в этом случае затронуты. И опять, не предоставляя клиентскому про-
цессу прав доступа к базовым объектам, подсистема предотвращает его неже-
лательное поведение. Это гарантируется благодаря невидимой на поверхности
неустанной работе системы защиты Windows NT.
Заключение
Процессы — это фундаментальное средство разделения работы и ресурсов в
Windows NT. Они позволяют ОС подразделять выполняемую ею работу на
функциональные единицы для эффективного использования процессора.
Процессы в Windows NT разбиваются на исполняемые единицы, называемые
потоками (threads). Потоки дают процессу возможность параллельно испол-
нять разные части его программы и оригинальным образом использовать про-
цессор, особенно на многопроцессорных компьютерах. Процесс состоит из
адресного пространства и набора ресурсов, совместно используемых всеми
его потоками.
Структура процессов исполнительной системы NT очень проста и гибка.
Это позволяет подсистемам среды реализовывать любую семантику', которая
необходима им для поддержки клиентов. Им предоставлена свобода в опреде-
лении иерархии процессов, реализации наследования процессов и инициали-
зации адресного пространства их клиентов способом, который они сочтут
подходящим. Они могут также управлять клиентскими процессами другими
способами, выполняя действия от их имени и осуществляя чтение их виртуаль-
ной памяти и запись в нее. Все эти средства находятся под контролем системы
защиты, которая проверяет, имеет ли процесс права доступа к объекту’, прежде
чем разрешает выполнение соответствующей операции.
В следующей главе более подробно рассмотрены структура подсистем
Windows NT и механизм локального вызова процедур (LPC), позволяющий
процессам клиентов и подсистем взаимодействовать друг с другом.
Г А А В A 5
WINDOWS И ЗАЩИЩЕННЫЕ
ПОДСИСТЕМЫ
Во время разработки Windows NT ее называли в прессе то “операционной сис-
темой-хамелеоном”, то “матерью всех операционных систем”, а один раз — даже
’’многоголовой Гидрой”. Этими причудливыми названиями она обязана своим за-
щищенным подсистемам, а особенно подсистемам среды.
Как следует из названия “Windows NT”, 32-разрядная версия Windows пре-
доставляет пользовательский интерфейс для исполнительной системы NT. С
точки зрения пользователя Windows NT выглядит как Windows на MS-DOS. Од-
нако для программиста Windows NT принимает разные обличья.
Идея, что ОС может выполнять разные типы программ, нс нова. Она при-
шла в Windows NT из ОС Mach, которая была разработана для поддержки несов-
местимых версий API UNIX. Эта задача решается в Mach путем реализации раз-
личных сред API в виде серверных процессов пользовательского режима.
Windows NT использует тот же подход для достижения разнообразных целей.
С самого начала разработки Windows NT предполагалась нс замена, но
расширение API Microsoft, чтобы существующие приложения можно было про-
должать использовать, пока разрабатываются новые. Самым важным результа-
том этих усилий стал новый 32—разрядный интерфейс Windows, называемый
Win32 API. Win32 API обеспечивает приложениям доступ к возможностям про-
двинутой ОС, недоступным в API 16—разрядной Windows. Однако, кроме выпол-
нения приложений Win32, Windows NT может исполнять приложения MS-DOS
и 16-разрядной Windows, а также многие из приложений OS/2 и все приложе-
ния, совместимые с POSIX (IEEE 1003-1).
Для достижения такой гибкости исполнительная система NT по необходимо-
сти решает самые общие задачи. Она сама выполняет создание процессов и пото-
ков низкого уровня, планирование потоков, управление памятью, обработку-' пре-
рываний и ввод—вывод; вто же время она полагается на серверы пользовательского
режима в отношении красот граф!гчсского интерфейса пользователя и других
средств, необходимых приложениям и пользователям. Используя системные серви-
сы NT в качестве основы, отдельные серверы пользовательского режима реализуют
API Win32, 16-разрядной Windows, MS-DOS, POSIX и OS/2. В Windows NT могут
сосуществовать любое количество API и сред выполнения приложений*.
* В качестве примера можно назвать подсистемы РМ и OpenNT, позволяющие исполнять приложе-
ния для Presentation Manager и совместимые со стандартом POSIX.1003.2 соответственно. Эти подси-
стемы нс входят в базовую систему и поставляются дополнительно.
Iaobo t>. Windows и защищенные подсистемы
WINDOWS NT
Серверы, реализующие среды API, называются защищенными подсистема-
ми (protected subsystems), а в частном случае подсистемами среды (environment
subsystems). Хотя у каждой системы были свои разработчики, общий клиент^
серверный подход и две первые подсистемы среды (рудиментарные версии OS/
2 и POSIX) разработали Стив Вуд и Марк Люковски. Они и определили следую,
щие цели разработки подсистем среды Windows NT:
« Каждая подсистема должна быть устойчивой (robust), т. е. клиентские при.
ложения не должны иметь возможности отрицательно влиять друг на друга
или на подсистеме- в целом. Кроме того, подсистема не может произвольно
воздействовать на другую подсистему win ее клиентские приложения.
И Производительность (performance) подсистемы должна быть нс хуже
производительности эмулируемой сю ОС. Например, пргиюжения ддя
16-разрядной Windows должны работать под Windows NT так же быст-
ро, как и на 16-разрядной Windows. Аналогично, пргиюжения MS-DOS
должны работать под Windows NT не хуже, чем в “оригинале”.
Каждая подсистема должна соответствовать требованиям правитель-
ства США к защищенной среде операционной системы (secure operating
system environment). В эти требования входит полная защита памяти
процесса от других процессов и управление доступом каждого клиент-
ского процесса к ресурсам подсистемы и других клиентов.
Я Подсистема должна взаимодействовать (interoperate) с другими под-
системами, если этого пожелает пользователь. Например, приложения
16-разрядной и 32-разрядной Windows должны быть способны пере-
давать данные через глобальный буфер обмена либо при помощи DDE
или OLE. Один и тот же интерпретатор командной строки текстового
режима должен запускать программы MS-DOS, OS/2 или POSIX и обес-
печивать, при необходимости, переназначение ввода—вывода между
ними. Приложения текстового режима всех типов должны быть спо-
собны посылать результаты на стандартное устройство вывода с авто-
матическим отображением их ОС в соответствующем окне.
В данной главе не рассматривается подробно каждая подсистема. Вместо
этого мы сосредоточимся на средах Win32, 16—разрядной Windows и MS- DOS.
Подсистема среды Win32 — это критически важный компонент Windows N Г.
реализующий системные интерфейсы пользователя и прикладных программ
Среды 16-разрядной Windows и MS-DOS важны для совместимости с существу-
ющими пргиюжениями.
В первом разделе главы описывается клиент-серверная .модель Window*’
NT и причины, по которым она была выбрана. Второй раздел анализируе т спо-
собы взаимодействия между подсистемами. Третий раздел посвящен подсистеме
Win32. Далее следует* описание сред MS-DOS и 16-разрядной Windows, и запер'
шается глава обсуждением системного средства передачи сообщений.
Общие сведения о защищенных подсистемах
Защищенные подсистемы Windows NT это серверные процессы пользонВ'
тельского режима, создаваемые ОС во время ее загрузки. После создания он*1
функционируют постоянно, обрабатывая сообщения от прикладных процессов
и других подсистем. Если подсистемы среды реализуют API, то подсистемы дру-
гого типа, называемые неотъемлемыми подсистемами (integral subsystems), вы-
полняют задачи, необходимые для функционирования ОС. Большая часть систе-
мы защиты Windows NT реализована как неотъемлемая подсистема; сетевые сер-
веры также могут быть выполнены в виде неотъемлемых подсистем1.
Любая защищенная подсистема функционирует в пользовательском режи-
ме, вызывая системные сервисы исполнительной системы NT для обращения к
функциям ядра ОС. Сетевые серверы могут исполняться как в пользовательском
режиме, так и в режиме ядра, в зависимости от способа реализации. Подсистемы
Windows NT показаны на рис. 5—1.
Подсистемы взаимодействуют между собой путем обмена сообщениями.
Например, когда пользовательское пргиюжение вызывает функцию API, предос-
тавляющая се подсистема среды получает сообщение и обрабатывает его, вызы-
вая системные сервисы NT win посылая сообщения другим подсистемам. По
окончании обработки подсистема посылает сообщение, содержащее результа-
ты, обратно прикладной программе. Эта передача сообщений и друтие действия
защищенных подсистем невидимы для пользователя.
LPC
Рис. 5-1. Защищенные подсистемы Windows NT.
i
1 Сетевые серверы moivi бы и» либо неотъемлемыми подсистемами, либо драйверами Встроенный
сервер Vv indows NI реализован как загружаемый драйвер, однако будущие сетевые серверы могут
быть выiк>лi lei Iы в виде i юдсистем.
“Клеем”, на котором держится клиент-серверная модель Windows NT, 5J1;
ляется механизм локального вызова процедур (local procedure call, LPC). При
мощи этого механизма клиенты выдают запросы серверам, а серверы отвечав
клиентам. LPC — это оптимизированная для локального применения Bepci15J
более общего механизма передачи сообщений, удаленного вызова процедур
(remote procedure call, RPC), который используется для связи между клиентский
и серверными процессами на разных машинах в сети.
LPC предоставляет несколько способов передачи сообщений между клиец.
тами и серверами: один используется для коротких сообщений, другой —
длинных, а третий специально оптимизирован для подсистемы Win32. Кажд^
подсистема создает порт (port), через который другие процессы могут общащ
ся с ней. Порты являются объектами исполнительной системы NT.
В данном разделе рассматривается преимущественно история клиент-
серверной модели Windows NT, т. е. ее развитие на ранних стадиях разработки
Windows NT. В первом подразделе описана роль клиент-серверной модели ц
достижении целей проекта Windows NT. Второй подраздел посвящен главному
вопросу при использовании клиент-серверной модели: производительности.
1 Почему используется модель клиент-сервер?
Реализация частей ОС в виде серверов пользовательского режима — существен-
ная особенность Windows NT, оказывающая большое влияние на всю работу си-
стемы. Хотя клиент-серверный подход не уникален для ОС, он нарушает тради-
цию. До самого последнего времени большинство ОС следовали либо монолит-
ной, либо послойной модели. При этом ОС работала в привилегированном ре-
жиме процессора (или, возможно, в нескольких привилегированных режимах),
отличавшем ее от непривилегированных приложений. Более того, как в моно-
литной, гак и в послойной модели ни одна из частей ОС не была отдельным
процессом. Вместо этого система создавала процессы пользовательского режи-
ма для выполнения приложении, а код ОС выполнялся для обслуживания прило-
жений, при вызове системных сервисов или при внешних прерываниях.
В противоположность описанному выше, Windows NT состоит из двух
частей: традиционной части и набора “приложений” пользовательского режи- ।
ма, предназначенных для выполнения различных задач ОС. “Приложениями 1
являются защищенные подсистемы Windows NT. Как и обычные приложения
они выполняются внутри процесса с отдельным адресным пространством. Ядр°
исполнительной системы NT направляет их потоки иа выполнение, в точности
так же, как делает это с другими приложениями.
Windows NT использует защищенные подсистемы для того, чтобы:
СО'
ОС
Предоставить несколько интерфейсов прикладных программ (API),
хранив при этом простой и легкий для сопровождения базовый код
(исполнительной системы NT).
Изолировать базовую ОС от изменений или расширений предостав-4’1
смых API.
Объединить глобальные данные, необходимые всем API, и в то же в)"*'1*
отделить глобальные данные, необходимые только одному' API от Д;11'
пых, необходимых другим API.
!' • Защитить среды API от приложений и друг от друга, а также защитить
базовую ОС от разных сред.
£ Обеспечить возможность расширить ОС в будущем за счет новых API.
Предоставление нескольких API (первый пункт в списке) было важной за-
дачей Windows NT и было связано с дилеммой, разрешение которой не было
очевидным. Данный подраздел излагает историю дискуссии о путях достижения
цели и описывает причины, по которым была выбрана модель клиент-сервер.
1 Поддержка нескольких сред
Как говорилось в гл. 1, “Постановка задачи”, первоначально от Windows NT
требовалась поддержка прежде всего интерфейсов программирования OS/2 и
POSIX, с возможностью добавления других API в будущем. Исходя из этих пред-
положений, разработчики и начали проектировать структуру NT (таким было
название системы в 1988 году).
При первом же исследовании вопроса в 1988 году разработчики поняли,
что просто реализовать несколько API недостаточно, так как API не существуют
в пустоте. Например, приложение OS/2, вызывающее DosExecPgmQ для созда-
ния процесса и запуска программы, законно ожидает от этой функции создания
процесса и возвращения корректных значений. Кроме того, и в этом суть про-
блемы, приложение также предполагает', что созданный процесс будет вести
W себя в точности так же. как он ведет себя в настоящей OS/2. То же самое верно
и для приложений Windows, MS-DOS и POSIX; т. е. функция API и нижележащая
среда выполнения программ (underlying execution environment) должны быть
полностью совместимы с оригинальной средой приложения данного типа. Каж-
дая ОС имеет разную структуру процессов, разное управление памятью, разную
й? обработку исключений и ошибок, разные механизмы защиты ресурсов и семан-
W тику' доступа к ф>айлам и ввода-вывода. Как создать среду выполнения, которая
будет совместимой с несколькими разными ОС? Этот вопрос был самым труд-
ным при проектировании Windows NT.
Разработчики начали с исследования API OS/2 и POSIX и попы тались выб-
рать для NT структу'ру, которая удовлетворяла бы обоим. Дополнительная цель
состояла в том, чтобы обеспечить возможность предоставления системой но-
вых, еще не созданных, API в будущем. (API Windows и MS-DOS, конечно, были
очевидными вариантами.)
Первая идея заключалась в создании стандартной послойной ОС, предос-
тавляющей один из API в качестве базовых системных сервисов. В то время ос-
новным вариантом был API OS/2. POSIX и другие будущие расширения должны
были иметь вид интерфейсов периода выполнения, вызывающих для выполне-
ния своих задач OS/2-подобные сервисы (см. рис. 5-2).
При более внимательном рассмотрении данного варианта стало ясно, что
поведение почти всех функций API OS/2 существенно отличается от поведения
функций POSIX и что для реализации данного варианта потребовалось бы из-
менение функций API OS/2. Например, процедуре создания процессов OS/2
DosExecPgm() потребовались бы дополнительная возможность копирования
содержимого адресного пространства родительского процесса в адресное про-
странство дочернего. (Стандартным поведением данной функции является ини-
циализация памяти дочернего процесса образом исполняемой программы.)
; Еще более неудобным было то, что невозможно было бы четко отделить семан-
ODD VV IlMUkJVVO ГАТТ
тику OS/2 от семантики POSIX или от семантики NT. Например, если многопо-
точное приложение OS/2 вызывает DosExecPgmQ и случайно задает опцию для
POSIX, то может произойти сбой ОС, так как NT не предполагает, что процесс
POSIX может иметь более одного потока. Bi юслсдствии первый вариант проекта ji
был отвергнут, гак как не мог обеспечить ОС устойчивость, легкоеть сопровож-
дения и расширяемость. |
Второй вариант предполагал создание ОС с двумя API, OS/2 и POSIX, но- . j
мещенных непосредственно в NT с исполнением в режиме ядра, как показано ' '
на рис. 5-3.
Тлава b. Windows и защищенные подсистемы
В этом варианте слои API не поддерживали бы глобальные данные и не
отслеживали бы состояние процессов, памяти и т. д., а просто вызывали бы
слой NT, реализуют! 1й базовую среду ОС, которая поддерживает семантику как
POSIX, так и OS/2.
Однако при более тщательном анализе эта идея оказалась лишь незначи-
тельно лучше предыдущей. Хота программа пользовательского режима не смог-
ла бы теперь вызвать NT с неправильными параметрами, NT по-прежнему нуж-
но было поддерживать две несовместимые среды исполнения приложений. На-
пример. процедуре создания процессов нужно было бы реализовывать семанти-
ку как OS/2, так и POSIX, используя флаг, задающий тип создаваемого процесса.
Аналогично, при завершении процесса NT потребовалось бы определять, не про-
цесс ли это OS/2, созданный с опцией EXECSYNG В этом случае идентифика-
тор процесса мог бы быть повторно использован другим процессом. Если же
это был процесс POSIX, порожденный не начальным процессом, NT нужно было
, бы посылать сигнал POSIX—типа; если процесс был лцдером группы сессии, то
исполнительной системе нужно было бы сгенерировать сигнал окончания
(hangup) для всех членов группы, использующих тот же управляющий терминал,
и возможно, освободить этот терминал, и проч., и проч. Очень запутанная схема.
f Структура процессов не была единственным источником затруднений.
L Из-за тонких различий между OS/2 и POSIX возникали проблемы в целом ряде
К областей — с таймерами, форматом времени, блокировкой ф>айлов, каналами,
К обработкой исключений и др. Для поддержки всех этих различий каждый про-
* цесс и поток в системе должны были “тащить за собой” груз описаний своих
? характеристик и указателей на специальные таблицы для отслеживания возмож-
ных комбинаций и действий. Простые функции, такие как ожидание дочернего
{ процесса (имеется и в OS/2, и в POSIX), было бы трудно реализовывать, так как
к потребовалась бы обработка двух слегка отличающихся случаев (не говоря уже
Р о будущих расширениях). Как удачно заметил Марк Люковски: “Список самых
невероятных интерфейсов на все случаи жизни, типа “цыпленок на вертеле” и
“шаманская пляска”, необходимый для реализации этого варианта, был угрозой
L для расширяемости и простоты сопровождения”. В самом деле, поддержка этой
структурой, помимо приложений OS/2 и POSIX, еще и приложений Windows и
jy MS-DOS была бы практически невозможна.
Проектировщикам системы пришлось рассмотреть несколько новых ва-
риантов. Им нужен был способ от деления базовых механизмов управления про-
цессами и памятью, обработки исключений и так далее от правил, управляющих
( представлением этих механизмов для прикладных программ. Кроме того, нужно
j было отделить глобальные данные и правила, требуемые различными слоями
\ API, от NT, чтобы она оставалась небольшой и целостной.
I. В 80-х годах некоторые из этих проблем были успешно решены ОС Mach.
Это клиент-серверная реализация UNIX, в которой механизмы ОС, такие как
управление памятью и планирование потоков, отделены от различных UNIX (и
не—UNIX) API, реализуемых серверами. Проектировщики Windows NT заимство-
вали у Mach этот подход и приспособили его для своих нужд. Полученный ре-
зультат показан на рис. 5-4. где существенным является добавление подсистемы
32-разрядпой Windows.
Исполнительная система NT — это обеспечивающая базовые функции ОС
общего назначения. Она реализует основные механизмы ОС и позволяет подси-
стемам среды самим определять правила и семантику, необходимые их прило-
жениям. Каждая подсистема среды независима от других и может вызывать базо-
ЭВЫ WINDOWS NT
Рис. 5-4. Структура защищенных подсистем Windows NT.
I
вые сервисы NT, необходимые для создания подходящей среды выполнения ее
клиентских приложений.
2 Защита памяти
В результате выноса API за пределы исполнительной системы NT было достиг! iy'
то четкое отделение “истинной” ОС от семантики и правил, требуемых различ-
ными API. В качестве дополнительной выгоды такая структура способствует до-
стижению другой важной цели Windows NT: она защищает среду API от пользо-
вательских приложений, а исполнительную систему NT — от сред API.
В OS/2 и 16-разрядной Windows для реализации API используется модель |
DLL В этой модели API реализуется одной или несколькими совместно исполь-
зуемыми DLL, связывание н обращение к которым осуществляется прикладным11 !
программами через обычные вызовы процедур. Система модифицирует испол- |
няемый образ программы, чтобы во время исполнения он содержал ссылки 1111
совместно используемые сегменты DLL (см. рис. 5-5).
Рис. 5-5. Модель DLL для реализации API.
Глава 5. Windows и защищенные подсистемы
Хотя DLL реализованы в Windows и OS/2 по-разному-, результат в обоих
случаях один и тот же: каждое приложение, использующее DLL, может модифи-
цировать данные, используемые всеми приложениями. В Windows NT такой сце-
нарий неприемлем, так как устойчивость и защищенность являются важнейши-
ми требованиями. Прикладная программа не должна иметь возможности нега-
тивно влиять па ОС или другие программы. Например, код Windows отслежива-
ет число отображаемых на экране окон. Если эти данные повреждены пользо-
вательской программой, то Windows может “зависнуть” шт начать работать с
ошибками, что повлечет за собой остановку тити даже повреждение выполняю-
щихся приложений. Windows NT не отказывается от применения DLL, но способ
их использования в OS/2 и Windows иллюстрирует проблему защиты кода и
данных в ОС. Чтобы ОС была полностью защищенной, ее код и данные не дол-
жны быть доступны приложениям пользовательского режима.
Клиент-серверная модель Windows NT прошла долгий пуль до решения
проблемы защиты памяти. Каждая защищенная подсистема исполняется внутри
процесса с собственным адресным пространством. Для получения доступа к
подсистеме приложение должно послать сообщение. Сервер, получив сообще-
ние, проверяет все его параметры, выполняет запрашиваемую функцию и воз-
вращает результаты вызывающей программе. Используя такуто процедуру, вызы-
вающая программа никогда не получает прямого доступа к адресному про-
странству подсистемы. Любые поддерживаемые подсистемой глобальные дан-
ные доступны только самой подсистеме.
На первый взгляд, может показаться, что приложение для Windows NT дол-
жно быть переписано так, чтобы посылать сообщения серверам вместо вызова
функций API, но это не так. Приложения по-прежнему связываются с DLL. Каж-
дая DLL содержит точки входа API, называемые заглушками (stubs), которые упа-
ковывают параметры функции API в сообщение и посылают его соответствую-
щему серверу. Сервер выполняет функцию и через LPC возвращает результаты
коду' DLL. DLL возвращает результаты прикладной программе обычным образом,
так что передача сообщения остается невидимой для прикладного программи-
ста. На рис. 5—6 это поведение показано на примере подсистемы Win32. Для
других защищенных подсистем механизм остается тем же самым.
Благодаря использованию такой модели приложение Win32, например,
теперь не может повредить глобальные структуры данных подсистемы Win32
или оказать отрицательное воздействие па другие приложения. Болес того, каж-
дая подсистема автономна и, таким образом, защищена от друтих приложений.
Подсистема может независимо создавать и поддерживать структуры данных, а
также определять особую семантику структуры процессов, обработки исключе-
ний и ошибок, ввода—вывода и т. д.
Кроме того, поскольку подсистемы — это приложения пользовательского
режима, они не MOiyr изменять данные исполнительной системы NT или вызы-
вать внутренние функции ОС. Единственный для них способ получить доступ к
исполнительной системе NT — это вызов системных сервисов. Пс т ребуется ни
сложной структуры колец, ни других громоздких механизмов защиты. Клиент-
серверная модель обеспечивает разделение между подсистемами и частью ОС,
выполняющейся в режиме ядра.
- В Windows DLL однократно проецируется в одно адресное пространство, доступное всем приложе-
ниям. OS/2 проецирует совместно используемые DLL в адресное пространство казудоио процесса, но
все процессы совместно используют данные DLL
ЭВЫ WINDOWS NT
Рис. 5-6. Модель API DLL в Windows NT.
Наконец, последнее преимущество клиент-серверной модели — это воз-
можность одновременной работы любого количества подсистем, поддерж! лаю-
щих множество сред API. Каждая подсистема — эчо просто процесс пользова-
тельского режима, чьи потоки могут выполняться каждый по отдельности, повы-
шая степень параллелизма. Все эти преимущества сделали клиент-серверную
модель подходящим решением для проекта Windows NT.
Соображения производительности
Более всего при выборе клиент-серверной модели для Windows NT разработчи-
ков беспокоила производительность. Вызов функции API или системного серви-
са в традиционной OG в общем случае, связан с меньшими накладными расхо-
дами, чем вызов API в клиент-серверной конфигурации.
Монолитные и послойные ОС реализуют свои системные сервисы в режи-
ме ядра. При вызове сервиса потоком пользовательского режима аппарачур3
перехватывает эч-от вызов и переводит процессор в режим ядра. После этого 0^
выполняет сервис; по окончании она переключаег процессор обратно в ноль30'
вательский режим и поток продолжает исполнять код приложения. На болыиНН
стве процессоров эта последовательность выполняется очень быстро.
Однако, когда в Windows NT приложение Win32 вызывает API Win32. н°Д'
ключается та часть ОС, которая работает не в режиме ядра. Если снова обр3'
литься к рис. 5-6, можно увидеть, что Win32 DLL вызывает системный сср»,,с
NT для посылки сообщения. (Сервис доставляет сообщение серверу и ждет, по^
Глава 5. Windows и защищенные подсистемы
сервер примет его, обработает и возвратит ответ. Для того, чтобы сервер полу-
чил и обработал сообщение, должно быть выполнено переключение контек-
ста (context switch), т. е. исполнительная система NT должна выполнить следу-
ющую последовательность действий:
1. сохранить контекст (текущее состояние процессора) клиентского потока;
2. выбрать для исполнения поток сервера и загрузить контекст этого потока;
3. выполнить функцию Win32 API, используя поток сервера;
4. сохранить контекст потока сервера;
5. снова загрузить контекст клиентского потока и обработать результаты
функции API.
В зависимости от используемых аппаратных средств, переключение контек-
ста вызывает большие или меньшие добавочные накладные расходы при систем-
ном вызове. Таким образом, поток, вызывающий функцию API, реализованную сер-
вером, теоретически должен сталкиваться при всяком таком вызове с большей
потерей производительности, чем в случае реализации функции API в виде сис-
темной ловушки. Так как производительность считалась критически важной для
успеха Windows NT, этот вопрос был тщательно рассмотрен проектировщиками.
Стоимость операции переключения контекста, т. е. сохранения состоя-
ния процессора для одного потока и его загрузки для другого потока, относи-
тельно постоянна. В зависимости от типа процессора, можно применить неко-
торые приемы оптимизации, такие как специальное упорядочение операции
загрузки и сохранения или сохранение и восстановление только необходимых
частей контекста. Дэйв Катлер (Dave Cutler), написавший код переключения
контекста для процессоров MIPS, и Брайан Уилман (Bry an Willman) и Ши Лин
Цонг (Shie-Lin Tzong), переписавшие его для CISC-процессоров Intel, очень
опытны в таких делах, так что все оптимизации, которые можно сделать про-
граммно, были сделаны.
Другим Диктором, влияющим на производительность при переходе от кли-
ента к серверу и обратно, является системное средство передачи сообщений.
Стив Вуд спроектировавший и реализовавший механизм LPC, снабдгш его гиб-
кими опциями передачи данных. Например, LPC предоставляет легкий способ
посылки коротких сообщений и эффективный способ посылки длинных. Тре-
тий метод передачи сообщений был создан специально для повышения про-
изводительности подсистемы Win32, что является важной задачей, так как эта
подсистема обрабатывает весь пользовательский ввод и генерирует весь графи-
ческий вывод в Windows NT.
Кроме гибкого, оптимизированного средства передачи сообщений разра-
ботчики Windows NT использовали некоторые “трюки”, сокращающие число
обращений клиента к серверу:
» Реализация функций API, которые нс используют и не модифицируют
глобальные данные, в DLL на клиентской стороне.
Хранение некоторых данных подсистем в исполнительной системе, или
их кэширование в DLL па клиентской стороне.
» Пакетирование клиентских вызовов API и посылка их серверу одним
сообщением.
ВЫ WINDOWS NT
Из трех названных стратегий самый большой выигрыш дает первая. Как
подробно говорилось выше, одной из основных целей использования клиент-
серверной модели было стремление гарантировать, что процессы нс смогут мо-
дифицировать глобальные данные, поддерживаемые некоторой средой. В со-
став этих данных входит такая информация, как число окон на экране для под.
системы Win32, таблицы rpai (сляции описателей для подсистем POSIX и OS/2. а
также собственные идентификаторы процессов и сессий, поддерживаемые неС-
ми подсистемами. Так как эти данные находятся в адресном пространстве под-
системы, для доступа к ним клиент должен послать сообщение.
Однако подробное рассмотрение различных API показывает, что их функ-
ции можно разделить на две категории: те, которые используют или изменяют
глобальные данные, и те, которые этого не делают, Функциям API второй группы
нет необходимости обращаться к подсистеме. Иными словами, они могут быть
реализованы непосредственно в DLL API, как показано на рис. 5-7. Для выполне-
ния своей задачи DLL вызывает базовые сервисы NT, полностью обходясь без
передачи сообщений и переключений контекста4.
Разработчики различных подсистем Windows NT приложили существен-
ные усилия для реализации в DLL наиболее часто используемых функций API.
Функции API Win32, например, возвращающие информацию о текущем потоке
или его процессе, и даже функции, изменяющие характеристики процессов и
потоков, реализуются в DLL Win32. Так как для получения необходимой hi 1фор-
' Код DLL хоти и используется приложениями совместно, защищен страничной .защитой “копиров-1
нис при записи” Подробнее см. гл. 6. “Диспетчер виртуальной памяти".
Глава 5. Windows и защищенные подсистемы
мации они могут вызывать сервисы NT, то им нет необходимости обращаться к
серверу Win32. Сходный подход применялся для других подсистем среды. Эта
стратегия позволяет поднять производительность часто используемых функций
API на тот же уровень, что и вызовы API в послойных или монолитных ОС.
Тщательное исследование показывает, что большинство функций API не
используют глобальных даш 1ЫХ и, таким образом, не требуют вызова сервера. Те
же функции, которым это необходимо, обычно являются редко используемыми
или уже и без того “дорогими1' сервисами, такими как создание процесса и от-
крытие файла. В подобных случаях расходы па переключение контекста и пере-
дачу сообщения незаметны пользователю.
Второй и третий тип оптимизации имеют более ограниченное примене-
ние, но тоже важны. Во втором случае, данные подсистемы хранятся в исполни-
тельной системе NT или кэшируются в DLL. Буквы идентификаторы устройств,
как упоминалось в гл. 3, “Диспетчер объектов и контроль доступа”, служат при-
мером данных подсистемы, хранящихся в исполнительной системе NT. И MS-
DOS. и OS/2 требуют наличия глобальных символов для букв дисков А, В и С, а
также других, которые могут быть созданы пользователем. Чтобы избежать вы-
зова сервера всякий раз, когда приложение ссылается на устройство, эти буквы
хранятся как поименованные объекты NT, чьи имена во время выполнения транс-
лируются диспетчером объектов в обозначенные буквами устройства. Аналогич-
но. подсистема Win32 кэширует глобальные данные в адресном пространстве
приложения. Например, когда приложение рисует объект, подсистема Win32 со-
храняет сто копию в DLL на клиентской стороне, так что DLL имеет данные для
выполнения большего количества функций API без обращения к серверу Win32.*
Третий тип оптимизации, изобретенный Чаком Уитмером (Chuck Whitmer),
архитектором графической части подсистемы Win32, состоит в пакетировании
информации на клиентской стороне и посылке ее серверу одним сообщением.
Например, приложение может последовательно вызывать несколько функций
рисования линий; DLL объединяет эти вызовы в пакет и посылает его на сервер
одним сообщением. Или, допустим, приложение устанавливает цвет пера. DLL
запоминает, что цвет пера был изменен и пересылает эту информацию на сервер
только тогда, когда что-нибудь будет выводиться на экран. Результатом такого
пакетирования является меньшее количество передач данных большего объема
между клиентом и сервером, что повышает производительность.
Повышение защиты и устойчивости, гарантируемое клиент-серверной
моделью для Windows NT, было настолько важным для разработчиков, что они
были готовы допустить десятипроцентное сокращение скорости выполнения
приложений, по сравнению с Windows 3.1 - Однако перечисленные здесь спосо-
бы повышения производительности существенно сократили количество функ-
ций API. которые на самом деле обращаются к серверу. Те же, которые обраща-
ются, были оптимизированы при помощи пакетирования и кэширования, а так-
же усовершенствованной формы LPC (описана в разд. 5-5). В результате при-
менения всех этих (и некоторых других) методов лишь несколько вызовов API
связаны со значительными накладными расходами, да и те существенно ниже
дссятипро! Щ1 ггной отмегки.
В XX indowx N I версии 4.0 были сделаны сущсспктшые архитектурные изменения в подсистеме
XX inS2. Эли изменения подробно описаны в примечании в разд. 5-2.2. Читая злу главу, необходимо
вместо слов "подсистема XX in.S2’ подставлять “подсистема клиент—сервер (CSK)", так как :тго назва-
ние наиболее точно отражает современную архитектуру Windows NT.
взаимодействие с подсистемами Windows NT
[одсистемы среды Windows NT взаимодействуют не только с клиентскими прн-
оженнями, когда те вызывают функции API; подсистемы также могут взапмо-
ействовать друг с другом. На рис 5-8 показаны некоторые защищенные подсн-
темы Windows NT и типичные взаимодействия между ними.
В дополнение к другим обязанностям, на подсистему Win32 возложено
правление пользовательским интерфейсом. Она управляет окнами па экране.
>тображает вывод других подсистем среды, а также принимает ввод от пользы-
ателя и направляет его соответствующей подсистеме или приложению. Под-
истема Win32 осуществляет запуск приложений по запросам Диспетчера про-
рамм Windows н командного процессора (консоли).
Кроме подсистем среды, расположенных в ряд наверху рисунка, показаны
акже две неотъемлемые подсистемы. Это системные компоненты, которые
юльзутотся защитой и возможностью параллельного выполнения, предоставл ис-
тыми структурой клиент—сервер. Подсистема защиты обрабатывает регистрацию
ользователя в системе, создает маркеры защиты для идентификации пользова-
Подсистемы среды
Текстовый ввод-вывод Текстовый ввод-вывод
Рис. 5-8. Взаимодействие подсистем.
тельского процесса и поддерживает базу данных с учетными записями пользовате-
лей. Сетевые подсистемы обрабатывают удаленные запросы. В Windows NT может
быть загружено более одной сетевой подсистемы (обычно называемой сетевым
сервером) для обработки запросов, приходящих по разным сетям.
В следующих подразделах более подробно рассмотрены два типа взаимо-
действий между подсистемами, которые происходят в ответ на определенные
действия пользователя. Взаимодействие первого типа имеет место, когда
пользователь пытается зарегистрироваться в системе, а взаимодействие второго
типа - когда он запускает приложение, не являющееся приложением Win32.
5.2.1 Регистрация пользователя в системе
Регистрация пользователя является новой особенностью Windows NT, предназ-
наченной для того, чтобы сделать систему истинно защищенной (как определе-
но правительством США). Регистрация не дает пользователям без соответствую-
щих полномочий возможности случайного или преднамеренного доступа к
данным других лиц.
Есть два способа зарегистрироваться в Windows NT: посредством интерак-
тивной регистрации и путем регистрации через сетевое соединение. Подсисте-
ма защиты гарантирует, что доступ к Windows NT получит только тот, кому это
право предоставлено системным администратором. В большинстве случаев
“право” означает, что о пользователе имеется запись в диспетчере учетных запи-
сей (SAM) — базе данных, содержащей имена пользователей, пароли и другую
информацию о защите.
Подсистему защиты разработали Джим Келли (Jim Kelly) и Клифф Ван
Дайк (Cliff Van Dyke), имеющие многолетний опыт работы с защитой и сетями.
Одной из их основных целей было обеспечить Windows NT гибкость в отноше-
нии количества и типов поддерживаемых ею внешних устройств регистрации
пользователей. Обеспечивающая это схема показана на рис. 5-9.
Пользователи могут вводить запросы либо с клавиатуры, подсоединенной
к системе Windows NT, либо по сети *. Сетевые запросы обычно являются запро-
сами на подсоединение к сетевому ресурсу и/или выполнение операций ввода-
вывода. В случае как интерактивного, так и удаленного запроса некоторый ло-
кальный процесс должен вмешаться и проверить законность доступа. Для сете-
вых запросов эту’ задачу выполняет встроенный сервер Windows NT или другой
сетевой сервер. В случае интерактивного запроса специальный процесс Win32
ожидает нажатия пользователем комбинации клавиш Ctrl+Alt+Del. При обнару-
жении этой комбинации процесс регистрации предлагает пользователю ввести
соответствующую i гнформа! уию.
Для идентификации пользователя необходима информация двух типов:
идентификационная и аутентификационная. Перной является имя пользовате-
ля, а второй его пароль. Однако система защиты Windows NT достаточно
гибка и позволяет проводить идентификацию при помощи, например, пласти-
ковой карточки, а для аутентификации пользоваться PIN-кодом. Аналогично,
Iki4iiii.ui с Vtindows Г\ I версии 3SI. появилась возможность встраивания в систему иных механиз-
мов .i\ icii i нфнкацпн. разрасхпаиных пользователем. Гак. в качестве устройства ввода информации
,11>1 ре1НСТр.Щ||11 можно использовать считыватель с магнитных карточек, хсчроис гво распознавания
ошсчасъон пальцев и т. и.
герактивная
истрация /
регистрацию пользователя
тленный
ipoc
тленный
ipoc
Win32 процесс\ (?) Аутентифицировать
регистрации Лч
в системе^/
соответствующий
аутентификационный
пакет
Сервер
NetWare
Сервер
Windows NT
Подсистеме
защиты
Аутентификационные
пакеты
Windows Сервер Windows NT Пакет для другой сети или устройства
нс. 5-9. Регистрация в системе и подсистема защиты.
ели для идентификации пользователей используется устройство сканирова-
ия сетчатки глаз или дакпиюскопическое, то информацией идентификации
удет имя пользователя, а информацией аутентификации — “отпечаток” глаза
ли пальца пользователя.
После получения аутентификационной информации подсистема защиты
роверяет ее с помощью аутентификационного пакета (authentification
ackage). К системе защиты Windows NT могут подключаться различные аутен-
фикационные пакеты, что позволяет легко обеспечить поддержку будущих
зтройсгв ввода. Однако при обычной регистрации Windows или сетевой аутеи-
фикационный пакет обращаются к базе данных SAM, и если пароль, введен-
ий пользователем, соответствует хранящемуся в базе данных, то аутентифика-
ионный пакет возвращает идет ггификатор пользователя и список групп, к ко-
эрым он относится.
Затем подсистема защиты получает дополнительную информацию из базы
анных локальной политики, включая данные о привилегиях пользователя и
бъемах квот. Наконец, подсистема защиты создает маркер доступа, представля-
щий пользователя, и передает маркер процессу регистрации в системе, как по-
азано на рис. 5—10. На этом регистрация пользователя в системе завершается.
В случае интерактивной регистрации Win32-npouecc регистрации обра-
ается к подсистеме Win32 для создания нового процесса и присоединения к
ему пользовательского маркера. В этом процессе подсистема запускает обо-
тчку пользователя. Обычно такой оболочкой является Диспетчер программ.
1к на рис. 5—10, хотя это может быть процессор команд POSIX или иной.
Рис. 5-10. Начало интерактивной пользовательской сессии.
При регистрации по сети сетевой сервер использует маркер доступа, что-
бы выполнить имперсонацию (“обезличивание”) пользователя и получить дос-
туп к системным ресурсам. Затем он может скопировать файл тит выполнить
любую другую операцию, запрашиваемую удаленным пользователем.
5.2.2 Выполнение приложений
После регистрации в системе интерактивного пользователя подсистема Win32
создает процессы для исполнения его приложений. Например, когда пользова-
тель щелкает мышью значок, подсистема Win32 направляет этот ввод Диспетче-
ру программ *. Как показано на рис. 5-11, Диспетчер программ, в свою очередь,
вызывает' подсистему Win32 для создания нового процесса и запуска в нем соответ-
ствующего приложения. Далее это приложение обращается к подсистеме Win32
для создания окон, посылки сообщений и т.д. Когда пользователь что-либо вводит;
подсистема направляет введенную информацию соотве тствующему приложению.
Подсистема Win32 связывает пользователя с остальной ОС. Пртитожения,
вызывающие API Win32, являются клиентами подсистемы Win32 и обслуживают-
ся непосредственно ею. Однако подсистема Win32 не может выполнять напря-
мую другие приложения, так как она нс реализует API 16-разрядной Windows,
MS-DOS, OS/2 или POSIX. Таким образом, всякий раз, когда пользователь запус-
кает приложение, чей формат исполняемого файла не распознается подсисте-
В Windows NT -1.0 — Explorer (Проколпик).
с. 5-11. Запуск приложения, использующего подсистему Win32.
>й Win324, она создает процесс для приложения, но вместо того чтобы начать
шолнение процесса, передает управление им другой подсистеме, как показано
рис. 5—12. После этого вызовы API, выполняемые приложением, направляют-
непосредственно подсистеме, реализующей необходимый API.
Windows NT не позволяет приложениям вызывать функции API разных
ед ОС (Win32 и POSIX, например), так как это не имеет смысла с точки зрения
реносимости приложений и, вероятно, приведет к ошибкам. Каждая подсис-
ма имеет свое представление о том, как устроен, например, процесс или опи-
гель файла, и маловероятно, что структуры данных одной среды будут соот-
гствовать структурам другой. Таким образом, после того как подсистема Win32
редала процесс другой подсистеме, он остается клиентом последней до само-
своего завершения. Подсистема же Win32 продолжает направлять приложе-
ю пользовательский ввод.
Кроме управления пользовательским вводом, подсистема Win32 также отр-
ажает на экране вывод приложения. С этой точки зрения подсистема Win32
аделяет пршюжения на два типа: графические и текстовые. Обычные прило-
ния Win32 и 16-разрядной Windows — графические по своей природе. Опп
пользуют меню и диалоговые окна, рисуют в окне текст и линии и т. д. В про-
зоположность этому, приложения текстового режима просто выводят строки
волов на экран в текущей позиции курсора. Обычно они запускаются коман-
>im процессором и по завершении работы возвращаются к подсказке команд*
строки. Приложениями текстового режима являются приложения MS-DOS.
не как CHKDSK и FORMAT, а также приложения OS/2 символьного режима5 п
: приложения POSIX (удовлетворяющие IEEE 1003.1).
самом деле нодсиегсма Win32 вызываем для загрузки приложения диспетчер виртуальной нами
ююлнптслыюй системы NT. Диспетчер виртуальной памяти определяет формат исполняемою
ла. возвращая подсистеме Vi iii.S2 с<к>пил стнующую информацию.
Н1ЛОЖСП11Я OS/2 Presentation Manager не поддерживаются в первом версии Windows NT
(V) Щелчок значка
приложения POSIX
Рис. 5-12. Запуск He-Windows-приложения.
Под Windows NT приложения текстового режима преобразуются, в неко-
тором смысле, в графические, так как их простой, построчный вывод отобража-
ется внутри окна. Для получения такого эффекта без необходимости переписы-
вания приложений текстового режима Тереза Стоуэлл (Therese Stowell), ранее
работавшая в группе файловых систем OS/2, разработала набор фу tiki (ий Win32
API, которые направляют вывод приложений символьного режима в текстовые
окна, управляемые подсистемой Win32. Эти окна называются консолями (con-
soles). Стандартная библиотека С, например, вызывает консольные функции,
чтобы направить в окно консоли стандартный вывод приложений POSIX. Анало-
гично, когда приложение OS/2 вызывает функции VIO или приложение MS-DOS
вызываетфункции INT(IO), подсистема суэсды OS/2 или MS-DOS, соответственно,
вызывает функщш консоли Win32 для отображения текстового вывода.
В Windows NT консольные окна располагаются среди графических окон, и
пользователи могут перемещать текст из одних в другие через буфер обмена.
Более того, с использованием новых консольных функций Win32 разработчики
могут создавать для Windows NT 32-разрядные приложения текстового режима.
Большинство из утилит командной строки, поставляемых с Windows NT, — это
Win32 приложения.
5.3 Подсистема Win32
Хотя под Windows NT могут выполняться приложения разных типов, в первую
очередь она является операционной системой Windows. Точнее говоря, это
старший член семейства ОС Windows. С появлением Windows NT приложения
Windows могут выполняться па разных компьютерах, начиная с самых малень-
ких ноутбуков и закапчивая большими многопроцессорными рабочими стан-
циями. Для разработчиков приложений это означает, что создание одною npi 1-
ложепня позволит их продукту исполпяткя па самом разп<юбразном компью-
тер! юм < >б< >рудова! ши.
,1 WINDOWS NT
T7XUBU О. vvii iuvvvj r
Как упоминалось выше, в начале разработки Windows NT предполагалось,
э это будет старший вариант ОС OS/2, с поддержкой также и API POSIX. Ис-
ключение с OS/2 на Windows произошло в середине разработки системы, ц
ло не только болезненным с точки зрения сотрудников и управления проек-
м (группе OS/2 пришлось выкинуть свой код и начать заново), но и несколько
последовательным с точки зрения проектирования ОС. Подсистема среды
ndows должна была быть подсоединена к исполнительной системе NT и за-
нить подсистему OS/2. Так как подсистема Windows должна была стать ос-
вным пользовательским и программным интерфейсом Windows NT, нужно
о создать среду “cynep-Windows”, расширяющую возможности, имевшиеся
16-разрядной Windows, посредством нового 32-разрадного API и других
сдвинутых средств.
Таким образом, создавая новую среду Windows, Скотт Людвиг (Scott Ludwig),
к Уитмер (Chuck Whitmer) и другие члены группы 32—разрядной Windows Лей-
i Педерсона (Leif Pederson) стали рассматривать существующее программное
еспечение для Windows через призму Windows NT. Среда Windows в NT дол-
га была обеспечить среду программирования, подходящую для рабочих стан-
[й старших моделей. Ей также надо было удовлетворять ряду требований ис-
•лнительной системы NT:
установить 32—разрядную, линейную модель памяти;
реализовать вытесняющую многозадачность;
гарантировать устойчивость и защиту.
Хотя все это повлекло за собой далеко идущие изменения в системе 16-
зрядной Windows, для разработчика и пользователя Windows NT является
>ивычной средой. Она предоставляет дополнительные средства, но везде, где
о возможно, сохраняет старую функциональность Windows. Для исполнитель-
да системы NT подсистема Win32 — это стандартное NT-приложение, пусть и
1Снь сложное. Она полностью переписана для Windows NT и использует в ка-
:стве основы базовые сервисы NT. Хотя эта подсистема выполняется как про-
вес приложения, Windows NT зависит от нее в плане взаимодействия с пользо-
телем и обеспечения среды программирования и API для других приложений.
Название подсистемы Win32 происходит от названия нового 32—разряд-
)го Windows API фирмы Microsoft. Этот API, доступный в Windows NT it MS-
OS, расширяет 16—разрядный Windows API нс только использованием 32-раз-
здной линейной модели памяти, но и более мощным набором функций ОС. В
in .32 добавлены такие средства, как ввод—вывод, сложное управление памятью,
гравление объектами, многопоточные процессы и защита, а также расширены
>сдства графики и управления окнами.
Подсистема Win32 не является целиком новой. Разработчики пытались
аксималыю использовать код управления окнами и пользовательского ишер-
ейса, взятый ими из Windows 3-0, удаляя и переписывая те фрагменты, которые
ельзя было сделать устойчивыми, безопасными, поддерживающими вытеспс-
ис и т. д. Они также заимствовали средства Windows 3-1, чтобы пользователь^"
4й интерфейс Windows NT был с нею совместим. С другой стороны, графичсс-
1я часть подсистемы Win32 является практически полностью новой; отдельная
эунпа разработчиков переделала средства графики с самых основ, используя,
о большей части, C++.
В следующих подразделах содержится общая информация об API Win32,
описание базовой структуры подсистемы Win32, а также рассмотрены некото-
рые аспекты, в которых устройство подсистемы Win32 отличается от устрой-
ства 16—разрядной Windows.
5.3.1 32-разрядный API
Microsoft затратила много энергии и ресурсов, чтобы Windows стала выдающей-
ся средой разработки приложений. В 1990 году Стив Балмер (Steve Ballmer), тог-
дашний старший вице-президент подразделения систем Microsoft, стал провоз-
глашать свои любимые новые лозунги для всех, кто мог его слышать: “Windows,
Windows, Windows!” и “Windows Everywhere!”6 (“Windows повсюду!”). Хотя его
бьющий через край юмор всегда вызывал смех на собраниях фирмы, второй
лозунг имел некоторый особый подтекст. Как говорилось в гл. 1, в Microsoft ви-
дели необходимость создания ОС старшей модели, которая могла бы использо-
вать новейшие достижения технологии аппаратного обеспечения. API Windows
3-0, который работал поверх MS-DOS, был ограничен в этом отношении. Чтобы
стать продвинутой ОС, этот API должен был эволюционировать.
API Windows нужно было обеспечить всеобъемлющую, сложную среду
разработки приложений, не ограниченную старыми программными техноло-
гиями и не полагающуюся на конкретную аппаратную архитектуру. Необходи-
мо было поддерживать большие объемы памяти, разнообразные процессоры и
многопроцессорные машины, а также создать защищенную среду для крити-
ческих приложений.
Несмотря на эти амбициозные цели, главным приоритетом Microsoft при
развитии API Windows было: сделать новый API совместимым с API 16-разряд-
ной Windows по именам функций, семантике и используемым типам данных
везде, где только можно. Все функции API Win32 должны были обеспечить об-
ратную совместимость для переноса существующих 16-разрядных приложений
для Windows под Windows NT.
Твердо помня об этой задаче, разработчики Windows и Windows NT опре-
делили следующие дополнительные цели проекта нового Windows API:
К Изменить API так, чтобы использовать 32—разрядную линейную мо-
дель памяти. API не должен более полагаться на сегментную модель,
установленную процессорами семейства Intel х86, чтобы освободить
приложения от ограничения в 64 Кбайт на размеры кода и данных и
позволить им достичь максимальной переносимости на RISC и другие
не сегментные платформы.
г Сделать этот API одинаковым и под MS-DOS, и под Windows NT, чтобы
разработчики могли запускать свои приложения на широком диапазо-
не машин, от младших моделей до самых старших.
* Сделать среду приложений защищенной путем введения системы
виртуальной памяти, где каждое приложение работает в отдельном
£
i
° Учитывая сто склонность к лозунгам, Балмера выдвинули на пост исполнительного вице-президен-
та World wide Sales and Support. После повышения on модернизировал свои лозу! и1 который егэл зву-
чать как “Windows, Windows, Windows tor customers, customers, customers!” (“Windows, Windows.
Windows для клиентов, клиентов, клиентов’”).
адресном пространстве, и предоставления в составе API механизмов
защиты объектов.
и Добавить в API средства ОС высокого уровня, такие как многопоточные
процессы, средства ввода-вывода, синхронизация, управление памятью
и поддержка национальных языков (интернационализация).
Для создания нового API Win32 разработчики Microsoft просматривали
IPI Windows 3-0 и модифицировали его так, чтобы он удовлетворял персчис-
1снным выше задачам. Затем Microsoft привлекла “подопытных кроликов” как
13 самой компании, так и извне, чтобы добиться большей простоты в исполь-
овании и переносимости.
Подсистема Win32 обеспечивает в Windows NT доступ приложений к АР]
Улп3'2. Так как система виртуальной памяти исполнительной системы NT ба-
ируется на использовании 32-разрядного линейного адресного пространства,
□дельного для каждого процесса, то приложения Win32 API имеют меныние
Ёладные расходы, чем приложения для API 16—разрядной Windows или MS-
S. В связи с этим Microsoft поощряет программистов использовать в новых
шожениях Win32 API, который доступен как в Windows NT, так и в MS-DOS.
Функции API Win32 имеют ряд типовых отличий от аналогичных функц| ш
PI Windows 3-0. Самое большое отличие состоит в том, что некоторые структу-
ы данных, такие как описатели, указатели и координаты для рисования, расши-
ены с 16-битного до 32—битного представления и более не используют сег-
ентную модель памяти. В тех случаях, когда параметры большей длины могут
□влиять на существующие приложения, API Win32 вводит новую функцию, с
эзможностями, аналогичными возможностям существующей функции — так,
гобы не ломать старых приложений и чтобы они могли быть со временем пере-
Ены под Windows NT. Например, формат целочисленных параметров и ужа-
лей был изменен с формата “сегментсмещение” на линейный, 32—битный
мат, а координаты функций рисования имеют длину 32 бига, а не 16.
Полностью новая группа функций API Win32 предоставляет продвинутые
юдства ОС, такие как ввод—вывод, синхронизация, управление памятью, защи-
и потоки. Хотя они и разрабатывались так, чтобы сохранить дух старого API
indows, новые функции более или менее непосредственно экспортируют ба-
вые сервисы NT, делая ее мощь доступной программистам Win32. И хотя мно-
е из средств Win32 напрямую заимствованы из исполнительной системы NT,
[И также были продублированы для MS-DOS. Однако, некоторые продвинутые
едства, напромер, асинхронный ввод-вывод, доступны только под Windows NT.
Еще одно повое средство, предоставляемое API Win32 — защита — пропи-
вает весь интерфейс. Защита Win32 была ]эеалнзована Джимом Андерсоном
m Anderson), разработчиком, чей обширный опыт включал, помимо всего про-
то. создание компьютеров контроля качества для заводов по производству дин-
елей компании ford Motor. Средства защита, разработанные им для подеш
чы Win32, являются расширениями (пользовательского режима) для средств
циты, встроенных Джимом Келли (Jim Kelly), Робертом Рейчелом (Robert
ichel) и другими в объектную архитектуру исполнительной системы NT.
Подсистема Win32 реализует защиту объектов гак же, как это делает нс
мнительная система NТ; она защищает совместно используемые объекты
ndows от несанкционированного доступа, помещая в них дескрипторы за
ты NT. Как и в исполни тельной системе NI, когда приложение в первый раз
обращается к совместно используемому объекту, подсистема Win32 проверяет
права приложения на это. Если проверка проходит успешно, то подсистема
Win32 позволяет приложению продолжаться.
Защита в подсистеме Win32 реализована для множества совместно использу-
емых объектов, часть из которых надстроены над базовыми объектами NT. В состав
объек тов Win32 входят “рабочий стол”, окна, ме1 но и, как и в исполнительной сис-
теме NT, файлы, процессы, потоки и несколько синхронизационных объектов.
Переработка для подсистемы Win32 некоторых частей графического ин-
терфейса пользователя Windows (обсуждается ниже) и добавление в API Win32
средств защиты сделали подсистему Win32, так же как и исполнительную систе-
му NT, устойчивой и защищенной.
5.3.2 Структура
В подсистеме Win32 сохранена базовая структура 16-разрядной Windows. Ее
компоненты показаны на рис. 5—13.
Рис. 5-13. Подсистема Win32.
Как описано в разд. 5.1.2, реализация функций API \\ in32 в пользовательском режиме приводит к
высоким накладным расходам. Даже описанные трюки нс позволяют в ряде случаев получи ть высо-
кой производительности. Узким местом долгое время оставалась производитель! кхть 1рафнчсской
системы н системы управления окнами Так как эти элементы (видеодрайверы, драйверы мыши и
клавиатуры и г.п.) постоянно взаимодействуют с аппаратурой, разработчики Windows NT -1.0 реши-
ли перенести наиболее общие* п часто используемые функции из пользовательскою режима в ре-
жим ядра. при лом фчнкцнп .могут исполняться без буферизации сов.место нс ноль гуемои намят
или парных iкм оков, а также трс-б\«л более редкого переключения контекстов потоков. Введенные
изменения позволили значительно повысить производительность Windows NT 4 О и снизить грсбо
ванпя к опера 1 нвной памяти
В исполни гелыл ю спет ем\ VI'были перенесены диспетчер окон (I SHR), интерфейс i рафпческпх
хстройс in (<»!>!) и дрлнве-ры графических устройств Днснс-|чер окон н нигср<|к.‘йс графических \с г-
ройств iciicpb ф\ нкционпруют в составе испо.-пппх-лыюй системы в режиме ядра, а фхикцип. рса
1
1изующис консоль, завершение работы и обработку' ошибок — в составе подсистемы клиент—сервер
CSR), выполняемой в пользовательском режиме. Новая структура изображена на рисунке.
lepenoc диспетчера окон и GDI в режим ядра позволил избавиться от большого числа сложных
частков кода. Приложения теперь могут осуществлять доступ к подсистемам с графическим иользо-
ательским интерфейсом точно так же, как они реализуют ‘‘базовые” (неграфическис) части VC*in32
lPI (ввод-вывод файлов или управление памятью), путем вызова ловушки в режиме ядра. При этом
ызываемый поток переключается в стек режима ядра, а все вызываемые параметры проверяются
сред тем, как будут использованы привилегированной подсистемой. Таким обозом исключаются
[ногочисленныс переключения процессов и потоков. Однако переключения, выполняемые в режп-
ie ядра, относительно дороги по сравнению с непосредственным доступом к коду’ или данным на
дном уровне привилегий, поэтому некоторые из трюков, применявшихся ранее (пакетирование и
эширование в клиентском адресном пространстве в пользовательском режиме), также используют-
я для повышения производительности.
несенные изменения не приводят к снижению надежности, так как а) реализация Win32 в режиме
дра полностью защищена от непосредственного доступа приложений и б) процесс Win32 рассмат-
ивается как критический компонент системы и в случае сю сбоя вся ОС завершит работу'.
Подсистема разделена на пять модулей: диспетчер окон, обрабатывающий
вод и управляющий отображением на экране; интерфейс графических уст-
юйств (GDI), представляющий собой библиотек}- для устройств графическою
ывода; функции ОС; консоль, обеспечивающая поддержку текстовых окон; и
C'in.32—драйверы графических устройств. Каждый компонент реализует функ-
ции API, которые прикладные программисты могут использовать для создания
рафических приложений. Вмес те эти интерфейсы составляют Win32 API.
Диспетчер окон делает внешний вид Windows NT похожим на внешний
ид Windows. On управляет окнами на экране, доставляет пользовательский ввоД
риложеииям, поддерживает стандартные объекты Windows, пересылает даи-
Клждый нз перечисленных компонентов выполнен в виде отдельной DLL DLL диспетчера окоп па
.шлется I iscr32. a DU. функций ОС Kernels2 Последнюю не следует пугать с ядром (kernel) М'1
пые в буфер обмена и из него, а также выполняет другие видимые и невидимые
задачи. Диспетчер окон также предоставляет функции API для создания графи-
ческого интерфейса пользователя в приложениях. Например, он избавляет при-
ложи 1ия от необходимости иметь дело непосредственно с устройствами, предо-
ставляя стандартные функции для получения информации от устройств ввода.
Диспетчер окон также отслеживает положение, размеры и взаиморасположение
окон на экране. Когда, например, пользователь изменяет размеры окна, диспет-
чер окон уведомляет об этом соответствующее приложение. Точно так же он
сообщает приложениям, когда они должны перерисовывать свои окна, а когда
те это делают — перерисовывает только видимые части окон. Диспетчер окон
также позволяет приложениям передавать данные через буфер обмена.
Компонент GDI подсистемы Win32 предоставляет богатый набор функций
API для вывода линий, фигур, символов и текста на графические устройства (ви-
деодисплей или плоттер), а также для выполнения сложных манипуляций с гра-
фикой. Диспетчер окон вызывает эти функции для прорисовки окон и других
элементов, а компонент консоли — для рисования текста в окне, однако прило-
жения могут вызывать функции API GDI непосредственно. В свою очередь, GDI
вызывает для отображения фигур и текста драйверы графических устройств, а
драйверы графических устройств обращаются для работы с аппаратурой уст-
ройств к драйверам устройств NT.
Подобно консольному компоненту, компонент ОС Win32 относительно
нов. Он позволяет приложениям осуществлять полный набор операций ввода-
вывода, манипулировать объектами ОС (в дополнение к графическим объек-
там), синхронизировать исполнение потоков с системными событиями и дру-
гими приложениями, выполнять сложные функции управления памятью, безо-
пасно использовать ресурсы и создавать многопоточные приложения. Эти
функции реализованы на базе средств исполнительной системы NT и вызыва-
ют системные сервисы NT напрямую.
5.3.3 Конструктивные изменения
MS-DOS/Windows — это маленькая, простая ОС. Она предназначалась для рабо-
ты на персональных компьютерах с небольшим объемом памяти и, конечно, нс
имевших быстрых современных процессоров Intel и RISC. На маленьких компь-
ютерах, где имеет значение каждый байт и каждый цикл процессора, было бы
непрактично делать Windows полностью надежной средой, так как обеспечение
этого требует определенной платы — размером и скоростью выполнения кода.
С другой стороны, Windows NT разрабатывалась как ОС, которая может
обслуживать произвольное число пользователей в сети и выполнять сложные
банковские или важные правительственные приложения. В средах такого типа
возможность того, что одно приложение повредит другим приложениям пли
“подвесит” ОС, неприемлема. Таким образом, устойчивость была важной целью
при создании подсистемы Win32.
Чтобы защитить ОС от приложений, диспетчер окон Win32 должен рабо-
тать несколько иначе, нежели старый диспетчер окоп. Группа разработчиков
диспетчера окон, возглавляемая Скоттом Людвигом (Scott Ludwig) — ветераном
программирования для Windows и Presentation Manager с 8-летним опытом, —
должна была сделать 32—разрядную версию более устойчивой и надежной сре-
дой, чем 16—разрядный диспетчер окон. Основные изменения были следующими:
:тройства ввода
5-14. Модель ввода 16-разрядной Windows.
десинхронизация модели ввода Windows;
Я схема вытесняющего планирования потоков;
добавление проверки описателей объектов и блокировок объектов.
Первое изменение связано с тем, как подсистема Win32 обрабатывает
эльзовательский ввод (с нажатиями клавиш и кнопок мыши). Модель ввода 16-
1зрядного диспетчера окон была синхронной, т. е. весь пользовательский ввод
эмещался в одну очередь (“первым пришел, первым обслужен”) и посылался
эиложениям тогда, когда они его запрашивали. После ввода пользователь дол-
ей был ждать, пока приложение его обработает, прежде чем мог быть обраб< >-
in последующий ввод. Так как в данный момент времени выборку ввода могло
гущсствлять только одно приложение, каждое из них должно было свосврс-
енно выбирать ввод из очереди, ч тобы все приложения выполнялись без по-
ех. Синхронная модель ввода показана на рис. 5-14-
Иногда при использовании этой модели возникали проблемы. Какое—ни
'дь приложение могло "зависнуть” и перестать выбирать ввод или не имело
)зможпости выбирать его быстро из-за сильной занятости. В таких случаях
•бота других приложений останавливалась, так как они нс получали ввод, пс-
Устройства ввода
Очереди ввода
Считывает ввод
Считывает ввод
Считывает ввод
Приложение'
Рис. 5-15. Модель ввода Win32.
Приложение 2
Приложение 3
обходимый для продолжения. С точки зрения пользователя это выглядело как
“зависание” ОС".
Потребовалась значительная переделка модели ввода 16—разрядного дис-
петчера окон, но в результате устойчивость подсистемы Win32 сильно повыси-
лась. В новой модели ввода, разработанной Дэвидом Персоном (David Pehrson)
и Скоттом Людвигом, каждое приложение имеет отдельную очередь ввода, как
показано на рис. 5—15.
При получении пользовательского ввода подсистема Win32 немедленно
определяет, для какого приложения он предназначен (проверяя, какое окно явля-
ется в данный момент активным, и где расположен указатель мыши). 32—разряд-
ный диспетчер окон помещает ввод в соответствующую очередь ввода, и прило-
жение выбирает его по мере своей готовности. Если по некоторой причине при-
ложение прекратило выборку ввода, то на других процэаммах это нс отражается.
Вторым существенным изменением в подсистеме Win32, по сравнению с
16—разрядной Windows, является полная поддержка вытесняющей многозадач-
ности. В ус тойчивой ОС неприемлема ситуация, когда одно приложение пере-
стает работать, и у ОС нет способа вмешаться или завершит ь исполнение при-
ложения. 16—разрядная Windows рассчитывает па то, что приложения время <п
времени сами освобождают процессор, позволяя выполняться другим програм-
мам, но это не всегда имеет место в действительности. В Windows NT подсисте-
ма Win32 (опираясь на существенную поддержку ядра NT) вынуждает приложе-
ния освобождать процессор. Каждый поток приложения может выполняться
только на протяжении выделенного ему кванта времени. После этого ядро NT
прерывает выполнение потока и проверяет; есть ли необходимость исполнения
потока с более высоким приоритетом.
Используя вытеснение, подсистема Win32 не только вынуждает приложе-
ния освобождать процессор, но может и принудительно завершить приложение
Win32. Например, если приложение зависло из-за ошибки в нем или если
пользователь просто не хочет больше ждать, он может воспользоваться кнопкой
End Task (Завершить задачу) в Windows Task Manager. Работая в 16-разрядной
Windows, ошибочное приложение может не допустить своего завершения или, в
особо тяжелых случаях, даже не дать Task Manager отобразить свое окно на эк-
ране. В Windows NT, однако, подсистема Win32 обращается для принудительно-
го завершения приложения к исполнительной системе NT, и это обращение
всегда успешно. Поскольку поток приложения построен на основе объекта-
потока NT, диспетчер процессов посылает’ сообщения в порт завершения пото-
ка. Подсистема среды, отвечающая за данное приложение, получает’ это сообще-
ние и освобождает’ любую поддерживаемую ею глобальную информацию отно-
сительно завершенного приложения.
Кроме десинхронизации модели ввода и реализации вытеснения, подсис-
тема Win32 выполняет проверку описателей объектов В 16-разрядной Windows
описатели объектов иногда вызывали проблему, так как ОС предполагала, что
приложения всегда передают ей правильные описатели — т. е. такие, которые на
самом деле являются ссылками на те объекты, на которые должны указывать
Если же вместо описателя окна приложение передавало нечто постороннее,
системное программное обеспечение могло прийти в ужасное замешательство.
В противоположность этому, подсистема Win32 проверяет содержимое
описателей, передаваемых приложениями. Как и описатель объекта NT. описа-
тель объекта Win32 — это индекс в таблице. Описатель и соответствующий ему
элемент таблицы содержат определенную информацию об объекте, на который
ссылается описатель. Подсистема Win32 в состоянии проверить, что описатель
указывает’ на объект именно того типа, который требуется. Она даже может оп-
ределить, что описатель указывает на нужный экземпляр данного типа. В добав-
ление к проверке описателей, Win32 реализует разновидность удержания объек-
тов, аналогичную той, что используется исполнительной системой NT. В 16-раз-
рядной Windows приложение могло уничтожить объект, который все еще ис-
пользуется ОС, что вело к неприятным системным ошибкам. Подсистема же Win32
поддерживает для необходимых ей объектов счетчик ссылок. Приложение по-
прежнему может “удалить” объект, но система не уберет его из памяти до тех
пор, пока он продолжает использоваться.
Компонент GDI Win32 не является просто модернизацией 16—разрядной
версии — он полностью переписан. Новая версия разработана Чаком УитмероМ
и написана группой, руководимой Кентом Даймондом (Kent Daimond). Нерв011
задачей для компонента GDI подсистемы Win32 была замена ассемблерного
кода переносимым кодом на С, а также реорганизация внутренней работы Д-,1>1
поддержки некоторых продвинутых возможностей. В состав новых средств GD1
входят кривые Безье, дающие пользователям графических пакетов более тонки1’
средства рисования дуг; траектории (paths), позволяющие создавать объекты про-
извольной формы при помощи последовательности команд рисования; транс-
формация объектов, дающая возможность приложениям выполнять отображе-
ние из одного координатного пространства в другое; и наконец, корреляция
объектов, средство, при помощи которого приложение может легко определить,
перекрывается ли данный объект или область с другими.
Другим конструктивным изменением в GDI Win32 является новый интер-
фейс драйвера устройства, созданный на основе обобщенного опыта работы
программистов группы GDI как с 16—разрядной Windows, так и с Presentation
Manager. Этот интерфейс превосходит по своим возможностям обоих предше-
ственников, давая более тонкие способы контроля драйверам графических уст-
ройств Win32 (которые отвечают за создание изображений в аппаратно—зависи-
мом формате и посылку их на устройства вывода). В частности, GDI настраивает'
данные, которые он посылает1 драйверу устройства, в зависимости от набора по-
нятных драйверу операций. Например, если данный драйвер “понимает” кривые
Безье, то GDI передает’ их ему целиком. В противном случае GDI разбивает’ кривую
на простые линейные сегменты, прежде чем послать ее драйверу. Кроме того, в
GDI включены новые мощные функции создания битовых изображений, которые
программисты могут, в частности, использовать при создании драйверов диспле-
ев и принтеров вместо того, чтобы писать свои собственные функции. Благодаря
этой поддержке значительно сокращается время наш юания и отладки драйверов
устройств. Разработчики могут возложить на GDI большую часть работы, добавляя
в драйвер устройства только аппаратно—зависимые расширения и оптимизации.
Несмотря на все упомянутые выше улучшения, возможно, самым большим
изменением как в диспетчере окон, так и в GDI, была реализация Win32 в виде
защищенной подсистемы, т. е. в виде серверного процесса. Как описано выше в
этой главе, разработчики каждой из подсистем среды Window’s NT разделили
процедуры своих API на две группы — те, которые используют только локальные
данные, и те, которые используют глобальные данные. Первая группа в целях
повышения производительности может’ быть реализована в DLL клиентской
стороны. Вторая же должна быть реализована в адресном пространстве подси-
стемы, чтобы глобальные данные оставались защищенными, но по-прежнему
доступными всем клиентам подсистемы. Это изменение повлияло на выбор спо-
соба написания приложения Win32, особенно в случае вызова функций GDI.
Хотя GDI рассматривает’ почти все данные как локальные в клиентском
процессе, при прорисовке объектов все процессы совместно используют одно
устройство вывода — экран. Таким образом, экран фактически относится к “гло-
бальным данным", и функции GDI, изменяющие его состояние, должны быть
реализованы в сервере Win32, а нс в DLL клиентской стороны. Чтобы обеспе-
чить для этих функций максимальную скорость работы, GDI применяет не-
сколько оптимизаций. Например, чтобы изменить цвет а на экране, приложение
может вызвать функцию GDI для установки цвета переднего плана, затем снова
вызвать GDI для установки цвета фона, после чего выполнить еще несколько
операций, прежде чем рисовать что-либо на экране. Вместо того, чтобы вызы-
вать подсистему при каждом вызове функции GDI, DLL сохраняет измененную
информацию в собственном буфере. Когда приложение рисует что-нибудь на
экране, DLL посылает подсистеме все измененные данные одним сообщением. В
представленном здесь примере подсистема обновила бы цвета экрана в DLL,
подождав с посылкой информации об изменениях серверу до тех пор, пока нс
удет выдан первый запрос на рисование. Кэширование атрибутов (attribute
ashing), как называется этот метод буферизации, минимизирует количество
[ереключений контекста и объем времени, затраченный на передачу сообще-
на! между клиентом и сервером.
Для уменьшения числа переключений контекста между клиентом и серве-
ом GDI использует аналогичный способ оптимизации, пакетирование (batching)
1акетирование — это метод, при использовании которого, например, DLL GDI
охраняет несколько вызовов функций в очереди и посылает их на сервер од-
1им сообщением, когда очередь переполняется или когда пользователь выпол-
зет ввод. При получении такого сообщения сервер Win32 последовательно
исполняет все функции, прежде чем управление возвращается клиенту. Прежде
юм использовать эту технику, разработчики GDI провели тесты и проверили, не
>удетли вывод на экран прерывистым или неравномерным. Тесты показали, что
[ызовы функций посылаются серверу достаточно часто, и вывод на экран про-
водит плавно и ровно.
Авторам прикладных программ следует иметь в виду эти методы оптими-
1ации производительности при создании новых многопоточных приложении,
юли два потока работают вместе, то их исполнение должно быть синхронизи-
ювано, чтобы гарантировать выполнение действий в надлежащем порядке. На-
гример, нужно учитывать, что результат не появится на экране сразу же после
[ызова потоком функции API. Вызов функции может сохранен в буфере потока,
эжидая своего вывода на экран. GDI предоставляет функцию GdiFIush(), при
юмощи которой поток может осуществить принудительную посылку кэширо-
ванных вызовов функций на сервер Win32.
Другим результатом использования модели клиент—сервер является то. что
приложения, которые постоянно изменяют и перерисовывают большие бито-
вые поля, могут работать медленно, в сравнении с прорисовкой аппаратно-не-
[ависимых образов с использованием вызовов GDI. Так как каждый объект или
Зитовый образ являются локальными для клиентского приложения, они должны
пересылаться в составе сообщения на сервер при всякой перерисовке экрана,
фш обеспечения оптимальной производительности приложениям следует либо
перерисовывать, по возможности, только измененные фрагменты битового об-
эа.за, либо рисовать при помощи функций GDI, что позволяет реализовывать
преимущества методов кэширования и пакетирования. Новый Win32 GDI API
предоставляет более полный, чем GDI API 16-разрядноп Windows, набор средств
эисования, необходимый сложным приложениям.
API MS-DOS и 16-разрядной версии Windows
Эдна из первых мыслей, которые приходят в голову потенциальному пользова-
гелю Windows NT, вероятно, такова: “Да, продвинутые возможности — это прс'
красно, но будут ли работать под Windows NT мои любимые приложения Д'1Я
MS-DOS и Windows?’’ Это важный вопрос, учитывая, сколько вложено пользова-
телями в существующие приложения. Ясно, что количество потенциальны*
пользователей Windows NT сильно зависит от возможности использования при-
ложений для MS-DOS и Windows, и так будет продолжаться еще долгое время. 11<>Д'
щржка этих пользователей была важным аспектом при разработке Windows N’T.
По счастью, модель клиент-сервер Windows NT может легко поддержи-
вать много сред исполнения приложений. Добавление сред для MS-DOS и
Windows потребовало сложной и кропотливой работы, по нс изменило общей
структуры системы.
Мэттью Фелтон (Matthew Felton), имеющий обширный опыт в области
MS-DOS и работавший ранее над средой совместимости с MS-DOS для OS/2,
возглавлял группу, разработавшую подсистемы MS-DOS и 16-разрядной
Windows для Windows NT. Эти два проекта были тесно связаны друг с другом и
имели набор общих основных целей:
* Обеспечить пользователям легкий переход от MS-DOS и 16-разрядной
Windows к Windows NT.
9 Позволить выполняться основным приложениям MS-DOS и 16—разряд-
ной Windows, в то же время защитив от них остальную систему.
* Обеспечить двоичную совместимость приложений между платформа-
ми CISC и RISC.
й Позволить приложениям 16-разрядной Windows выполняться наравне
с приложениями 32—разрядной Windows.
Для MS-DOS Windows является сложным графическим приложением, рас-
ширяющим возможности нижележащей ОС. Для Windows NT п MS-DOS, и 16—
разрядная Windows являются приложениями — подсистемами среды, которые
вызывают API Win32 и иногда базовые сервисы NT. На рис. 5-16 показано место
MS-DOS и 16—разрядной Windows в структуре Windows NT.
Подсистемы MS-DOS и 16—разрядной Windows работают в пользователь-
ском режиме, так же, как и другие подсистемы среды. Однако, в от личие от подсп-
16-разрядная Windows
на Win32 (WOW)
Отдельные приложения
режим
Рис. 5-16. Подсистемы MS-DOS и 16-разрядной Windows
Режим ядра
WINDOWS NT
стем Win32, OS/2 и POSIX, они сам! i по себе не являются серверными процессами
Приложения MS-DOS исполняются в контексте процесса, называемого вирпг^
альной DOS-машиной (virtual DOS-machine, VDM). VDM это приложение
Win32, которое создает полный виртуальный компьютер, исполняющий MS-D( )у
Например, оно позволяет приложениям MS-DOS исполнять машинные команд^
вызывать BIOS, осуществлять непосредственный доступ к некоторым устрой,
ствам и получать сигналы прерываний. Одновременно может выполняться люб< >с
количество процессов VDM, каждый в отдельном консольном окне.
Среда 16-разрядной Windows — это гибридное приложение, исполняю,
щееся в адресном пространстве процесса VDM. Для выполнения большинства
своих задач она вызывает API Win32, но иногда обращается и к сервисам NT.
Разработчики среды 16-разрядной Windows называют ее WOW, что является со-
кращением от Windows on Win32 (Windows на Win32).
Создание подсистем среды MS-DOS и 16—разрядной Window's в виде под-
систем пользовательского режима обеспечивает им ту же защиту7 кода и данных
которую имеют и остальные подсистемы. Это также защищает исполнительную
систему NT от проблем этих сред, так как доступ к исполнительной системе NT
осуществляется только через вызовы системных сервисов. Такая стратегия защи-
щает приложения MS-DOS от приложений 16—разрядной Windows и наоборот,
а также отделяет их адресные пространства от адресных пространств приложе-
ний 32-разрядной Windows.
Виртуальные DOS-машины
Виртуальная DOS—машина (VDM) — это сессия MS-DOS, создаваемая всякий
раз, когда пользователь запускает приложение MS-DOS из-под Windows NT.
Последняя допускает параллельное исполнение произвольного количества i 1ри-
ложений MS-DOS, причем они могут передавать через буфер обмена тексто-
вые данные друг другу и приложениям Windows.
Исполнение приложений MS-DOS под Windows NT — это трудная задача,
так как они зачастую написаны на ассемблере и предполагают наличие свобод-
ного доступа к памяти, устройствам и т. д. В настоящей многопользовательской
ОС приложениям MS-DOS нельзя давать полную свободу, однако, им необходи-
мо позволить выполняться как обычно. Садии Бхаратн (Sudeep Bharati) и Дэйв
Хастингс (Dave Hastings), основные разработчики VDM, разрешили это прот и-
воречие, помес тив каждое приложение MS-DOS в своп отдельный процесс —
VDM — с собственным виртуальным адресным пространством, содержании1
весь код MS-DOS и драйверы MS-DOS, необходимые для работы приложения”
Внутри своего адресного пространства приложение может делать все, что за-
благорассудится. Диспетчер виртуальной памяти исполнительной системы N'l
управляет тем, как приложение используют физическую память, и гарантирует,
что оно не будет перекрываться с другими процессами.
Когда пользователь щелкает значок MS-DOS (или значок приложения MS-
DOS), подсистема Win32 запускает в консольном окне командный процессор
7 Первоначальная среда MS DOS Windows NI использует исходный код MS-DOS 5.0 н. таким обра
зом, совместима с этой версией MS-DOS. Опа также совместима с I.IM- EMS 4.0, DPMI 0.9 и XMS 3.0.
VCP1 поддерживается на процессорах MIPS, но не процессорах Intel. Среда MS-DOS Windows NT ik
поддерживает также приложения, которые напрямую пишут на жесткий или тибкий диск, поскольку
это може т нарушить целостность системы.
[лава b. Windows и защищенные подсистемы
Windows NT. Последний отходит от используемой в OS/2 модели исполнения
32- и 16-разрядных команд разными командными процессорами. Хотя он и
выглядит как командный процессор MS-DOS, но одинаково способен выпол-
нять как 32-разрядные команды Windows NT, так и 16-разрядные команды MS-
DOS в одном п том же консольном окне, и даже поддерживает переназначение
вывода между7 приложениями командной строки. Когда пользователь вводит
команду, процессор команд просто вызывает функцию Win32 CreateProcess()
для запуска исполняемого файла. Если команда является программой MS-DOS,
то подсистема Win32 запускает процесс VDM, который загружает приложение
MS—DOS в адресное пространство VDM и исполняет его. Когда приложение MS-
DOS осуществляет вывод, VDM вызывает консольные функции Win32 для ото-
бражения этого вывода в своем консольном окне.
Во время своей работы приложение MS-DOS должно иметь дост уп к ОС
MS-DOS или, по крайней мере, к чему-то такому, что выглядит и работает как
MS-DOS. В сущности, VDM — это виртуальная ОС MS-DOS, исполняющаяся на
виртуальном компьютере с процессором типа Intel х8б. На рис. 5—17 изображе-
но адресное пространство VDM на машине Intel х869.
16-разрядная эмуляция MS-DOS создана на основе исходного кода MS-
DOS 5.0, за исключением поддержки файловой системы. Она располагается в
нижней части виртуального адресного пространства VDM, а приложение MS-
Обработчик ловушки
Доступно
620 Кбайт или более
Исходный код
MS-DOS 5.0
Рис. 5-17. Виртуальная DOS-машина (VDM).
* Схема и содержимое памяти остается примерно таким же и на платформах MIPS, по блок испол-
нения команд заменяется. На платформах MIPS блок исполнения команд эмулирует команды Intel с
использованием команд процессор:! MIPS. 'Этот код и виртуальные драйверы устройств, показанные
па рис. 5— IT созданы фирмой Insignia Solutions lad. Виртуальные драйверы устройств фирмы Insignia
для обеспечения совместимости используются н на платформах Intel, и на платформах MIPS.
WINDOWS NT
DOS загружается непосредственно над нею. Приложению доступно не менес
620 Кбайт памяти.
Хотя код, расположенный ниже 16-мегабайтной границы, используст
разрядные сегментные адреса, код, находящийся выше нее. написан с использц.
ванием 32-разрядной линейной адресации формата Windows NT. 32-разрядндя
часть виртуального адресного пространства VDM имеет сложную структуру
Здесь расположены драйверы виртуальных устройств и код 32-разрядной эму.
ляции MS-DOS, один и тот же вариант которого используется для всех процеу.
сорных архитектур. Блок обработки команд (instruction execution unit) является
машинно-зависимым. Его версия для Intel х8б, написанная Дэйвом Хастингсом
работает как обработчик ловушки (см. гл. 7, “Ядро”), перехватывая команды, вы.
зывающие аппаратные ловушки, и передавая управление обрабатывающему цх
коду, например, драйверам виртуальных устройств. На процессорах MIPS этот кщ
является эмулятором команд, преобразующим команды х86 в команды MIPS.
Драйверы виртуальных устройств играют роль прослойки между прило-
жениями MS-DOS и аппаратурой, подключенной к машине Windows NT. В со-
став первой версии среды VDM входят драйверы виртуальных уст ройств для стан-
дартных устройств ПК, включая мышь, клавиатуру, принтер, СОМ—порты и т. д,
32—разрядный код VDM обрабатывает операции ввода—вывода MS-DOS. пере-
хватывая их и вызывая для выполнения ввода—вывода либо функции Win32, либо
исполнительной системы NT. Например, для обработки запросов к СОМ-порту
VDM открывает соответствующий драйвер устройства и посылает ему коды уп-
равления вводом-выводом (IOCTL). Для обновления изображения па мониторе
поток VDM периодически проверяет видеоОЗУ, куда пишут приложения MS-DOS.
и вызывает консольные API Win32 для вывода изменений на экран.
Хотя одновременно может выполняться много сессий MS-DOS, на это рас-
ходуется относительно небольшой объем памяти. Первые 640 Кбайт виртуаль-
ной памяти каждого процесса VDM, а также области ниже 16—мегабайтной гра-
ницы не используются совместно разными VDM. Однако диспетчер виртуаль-
ной памяти обеспечивает совместное использование всеми VDM одной копии
32—разрядного кода, расположенного выше этой границы. Более того, так как
VDM —это обычный процесс пользовательского режима, она может быть цели-
ком откачана на диск. Это означаег, что диспетчер виртуальной памяти загружа-
ет в физическую память только те фрагменты кода MS-DOS 5.0 и кода приложе-
ния MS-DOS, которые фактически используются. Если в системе недостаточно
свободной памяти, то он временно переносит содержимое памяти приложения
на диск (подробнее об управлении виртуальной памятью см. гл. 6, “Диспетчер
виртуальной памяти”).
Приложения MS-DOS не являются многозадачными, так как каяедое из них
предполагает, что выполняегся па машине MS-DOS в одиночестве. Однако яДР°
NT работает с потоками MS—DOS так же, как и с другими потоками. Когда исте-
кает квант времени, выделенный потоку, ядро прерываег его выполнение и коп-
текст переключается на другой поток: исполнение потока MS-DOS можег возоб-
новиться позднее. Так как некоторые приложения MS-DOS большую часть врС'
мели находятся в цикле опроса клавиатуры (и “пожирают” циклы процессора)-
то среда VDM, обнаружив подобное состояние простоя, дает больший приори-
тет другим ожидающим потокам.
Глава b. Windows и защищенные подсистемы
5.4.2 Windows на Win32
Одной из основных целей среды 16-разрядной Windows (WOW) было сделать
различие между 16- и 32-разрядными приложениями для Windows незаметным
для пользователя. Пользователь запускает 16-разрядные приложения тем же спо-
собом. что и приложения Win32. Приложения обоих типов выполняются одно-
временно, внешне неотличимые одно от другого.
Хотя для пользователя 16— и 32—битные приложения выглядят одинако-
во, на самом деле они выполняются под управлением разных частей ОС. Среда
WOW, разработанная и реализованная Джефом Парсонсом (Geff Parsons), Мэт-
тью Фелтоном (Matthew Felton). Чанданом Чауханом (Chandan Chauhan) и
Рамакришной Нандури (Ramakrishna Nanduri), — это по сути многопоточная
VDM, каждый поток которой исполняет одно приложение 16—разрядной
Windows. Выполнение этих приложений в одном адресном пространстве мо-
делирует поведение 16-разрядной Windows, где все приложения однопоточ-
ные и работают в общем адресном пространстве. Для создания и управления
окнами 16-разрядных приложений среда WOW вызывает API Win32. В отно-
Устроиства
ввода
Очереди
ввода
Рис. 5-18. Модель ввода для среды WOW
Схема
•иртуамнюго
адресного
пространства
Блок обработки команд
32-разрядная эмуляция MS-DOS
Драйверы виртуальных устройств
16 Мбайт
640 Кбайт
Ядро Windows 3.1
Приложения
для Windows 3.x
32-разрядные диспетчер окон
и заглушки GDI
Диспетчер окон и заглушки GDI
16-разрядная эмуляция MS-DOS
4С. 5-19. 16-разрядная Windows на Win32 (WOW).
[ении пользовательского ввода среда WOW рассматривается как одно прпло-
ение Win32, см. рис. 5-18’.
Как и в случае приложения MS DOS, когда пользователь в первый раз за-
ускает 16-разряднос приложение для Windows, подсистема Win32 определяет,
го исполняемый файл работает под MS-DOS, и запускает процесс VDM. После
того VDM загружает среду WOW. Виртуальное адресное пространство WOW
DM показано па рис. 5—19.
Структура адресного пространства системы WOW сходна со структурой
дресного пространс тва процесса приложения MS-DOS. Внизу адресного про-
гранства находится тот же самый код MS-DOS, а непосредственно над ним —
од ядра Windows 3.1. Этот код, из которого удалена поддержка многозадачно-
го, обрабатывает функции управления памятью Windows 3.1, а также загружае т
сполняемые файлы п MS-DOS для 16-разрядных приложений для Windows,
гце выше в адресном пространстве располагаются диспетчер окон и процеду-
ы — заглушки GDI, над которыми находятся 16—разрядные приложения. Здесь
Гак же, как и и случае 16 разрядной версии Windows. запуск приложений в общем адресном про-
ранстве прпводт к снижению надежности, поскольку при ‘’зависании1’ одного из Win 16--прияо
-ний вес остальные также “зависают". Для повышения надежности в Window?» NT версии 3.51 pea
ззована возможность запуска 1о—разрядных приложении в раздельном адресном пространстве,
ри этом приложение заиускасюя не как новый поток в существующей WOW, а как новая WOW, т.с
к отдельный ноток. Понятно, что достигнутые при этом надежность и вытесняющая многозадач-
>сть 16—разрядных приложений для Vi inclows требуюi повышенных накладных расходов.
может быть загружено любое количество таких приложений, их код и данные
подкачиваются диспетчером виртуальной памяти по мере надобности.
Код многозадачности 16-разрядной Windows заменен в подсистеме WOW
се собственным кодом, вызовами Win32 API и кодом поддержки многозадачности
исполнительной системы NT. После того, как среда WOW запущена, подсистема
Win32 посылает ей сообщение всякий раз, когда пользователь запускает 16-раз-
ряднос приложение для Windows. В ответ WOW загружает это приложение в па-
мять и вызывает функцию Win32 CrcateThrcad(), ч тобы создать поток для выпол-
нения данного приложения. Хотя все остальные потоки в Windows NT могут вы-
тесняться, потоки WOW не вытесняются подсистемой Win32 для достижения со-
вместимости среды WOW с 16—разрядной Windows. Это не означает, что эти по-
токи Moiyr выполняться столько, сколько им заблагорассудится. Ядро по-прежне-
му может прервать выполнение потока WOW, чтобы могли выполняться другие
не—WOW потоки. Однако, когда ядро переключает управление образно на WOW,
оно выбирае т для продолжения работы только поток, прерванный последним; все
остальные потоки WOW блокированы до тех пор, пока текущий поток сам не
освободит процессор. Такое поведение эмулирует невытесняющую многозадач-
ность, на которую рассчитаны 16—разрядные приложения для Windows, не воз-
действуя на Win32 и другие приложения, выполняющиеся под Windows NT.
Выше границы 16 Мбайт в адресном пространстве WOW находится тот же
самый код, что и для процесса приложения MS-DOS - драйверы виртуальных
устройств MS-DOS, 32-разрядная эмуляция MS-DOS и машинпо—зависимый
блок обработай команд. Кроме того, имеется блок .32—разрядного кода диспет-
чера окон и GDI, соответствующий 16—разрядному коду в нижней части адрес-
ного прост ранст ва. Этот 32-разрядный код отвечает за трансляцию 16—разряд-
ных сегментных адресов в .32—разрядные линейные адреса. Например, когда 16-
разрядпое приложение для Windows вызывает функции диспетчера окон или
GDI, показанные на рис. 5-19, 16-разрядныс заглушки вызывают эквивалент! 1ые
32—разрядные функции API в верхней части адресного прост ранства подсисте-
мы WOW 32-разрядный код диспетчера окоп и GDI преобразует 16-разрядиые
адреса, переданные приложением, так чтобы они соответствовали 32-разряд-
ной линейной модели. Затем для выполнения операции вызывается API Win32.
Когда подсистема Win32 возвращает результаты, 32 разрядный код WOW пре-
образует адреса обратно в 16-разрядные, которые и возвращаются приложе-
нию. Так как 16-разрядный API на самом деле нс реализован в WOW, не гаран-
тируется нормальная работа под Windows NT 16—разрядных приложений для
Windows, которые зависят от внутренней структуры диспетчера окон или GDI.
5.5 Передача сообщений при помощи
механизма локального вызова процедур
В клиент серверной модели Windows NT многое зависит от успешной работы
механизма локального вызова процедур (LPC). Хотя, по иронии судьбы, каждая
подсистема должна по возможности воздерживаться от посылки сообщений LPC
(см. разд. 5.1.2), иногда подсистемам приходится это делать.
Если два потока относятся к од> юму и тому же прог гсссу, то они совместно
используют адресное пространство и могут легко взаимодействовать и обмени-
ваться данными. Они применяют простые механизмы Синхронизации для обес-
1Ы WINDOWS Ml
гечения доступа к данным в надлежащем порядке. Однако когда два потока на-
ходятся в разных процессах, им необходимо преодолеть пропасть между адрес-
1ыми пространствами либо при помощи копирования данных из одного про-
"гранства в другое, либо создав область совместно используемой памяти, види-
мую из обоих адресных пространств. LPC — это средство передачи сообщений
гредоставляемое исполнительной системой NT. Оно используется для обсспсче-
1ия связи между двумя процессами, клиентом и защищенной подсистемой (сер-
1ером), расположенными на одном и том же компьютере. LPC напоминает мо-
[ель вызова процедур, используемую стандартным средством удаленного вызо-
а процедур (RPC), которое применяется для передачи сообщений между клиент-
жим и серверным процессами на разных компьютерах. Посылая сообщение
1ри помощи RPC, приложение не знаег о том, что посылка сообщения имеет
гесто; приложение просто вызывает функцию API, которая выглядит так же, как
I любая другая функция. Процедура-заглушка упаковывает параметры функции
I обращается к средству RPC для посылки их удаленному серверу. Результаты
юзвращаются обратно по тому же каналу (подробнее см. гл. 9, “Сети”).
Средство LPC Windows NT работает аналогично RPC, но оптимизировано
[ля случая, когда процессы клиента и сервера находятся на одной машине. При-
ложение вызывает функцию API из DLL, а последняя выполняет действия, необ-
ходимые для посылки сообщения защищенной подсистеме Windows NT. В го
;ремя как RPC — это общий механизм, используемый разными ОС. средство LPC
шецифично для Windows NT и, таким образом, использует ее возможности для
повышения скорости и эффективности по сравнению с RPC общего назначения"'.
Средство LPC исполнительной системы NT обеспечивает три разных спо-
соба передачи сообщений, предназначенные для разных ситуаций:
в посылка сообщения в объект—порт, связанный с серверным процессом;
* посылка в порт сервера указателя на сообщение и передача сообщения
через совместно используемую память;
передача сообщения определенному поток}- сервера через особую об-
ласть совместно используемой памяти
Кроме того, LPC поддерживает хитроумный механизм обратного вызова
callback), позволяющий серверу запрашивать у клиента дополнительную инфор-
гацию в процессе обработки сообщения".
В следующем подразделе описано, как клиентский процесс устанавливает
вязь с серверным при помощи объекта-порта. За этим идет раздел, более деталь-
ю обсуждающий различные типы передачи сообщений и обратные вызовы LPC.
Эбъект-порт
1ри использовании любого из методов передачи сообщений LPC клиент дол-
жен установить канал связи с защищенной подсистемой, прежде чем он сможет
’ Средство LPC не доступно приложениям Win32 непосредственно, по им доступен RPC, В зависи-
мое ги от копфи1урэции, RPC использует LPC для локальной передачи сообщений и именованные
аналы для передачи сообщений между машинами. Приложения Win32 могут использовать либо
именованные каналы, либо RFC.
1 Обратные вызовы средства LPC исполнительной системы МТ не следует пугать с процедурами об-
«атнея'о вызова в приложениях Windows.
Рис. 5-20. Подсоединение и взаимодействие с защищенной подсистемой.
посылать ей сообщения. Исполнительная система NT, как и ОС Mach, использует
объект—порт в качестве средства установления и, в большинстве случаев, под-
держания соединения между двумя процессами.
К подсистеме может обращаться любое количество клиентов, и каждому из
них нужен надежный и защищенный канал связи. Для этой цели исполнительная
система NT реализует порты двух типов. Они имеют одинаковую структуру, но
различаются названиями и способами использования. Порты одного типа назы-
ваются портами соединения (connection port) и служат местом, куда клиентское
приложение может передать запрос на установление канала связи с сервером.
Порты соединения имеют имена, что делает их видимыми всем процессам NT. На
рис. 5-20 показано, шаг за шагом, как клиентский процесс устанавливает контакт
с защищенной подсистемой и передача каких сообщений за этим следует.
Чтобы соединиться с защищенной подсистемой, клиентский процесс от-
крывает описатель объекта-порта соединения этой подсистемы, после чего
посылает ей запрос на соединение. Сервер, один или несколько потоков кото-
рого ожидают подобные запросы, создаст в ответ два безымянных (и, таким
образом, неизвестных другим) объекта-порта связи, сохраняя у себя один опи-
сатель и возвращая клиенту второй. Клиент использует свой описатель порта
связи для посылки последующих сообщений защищенной подсистеме и ожида-
ния ее ответов. Подсистема использует свой описатель для аналогичного взаи-
модействия с клиентом.
На рис. 5—21 приведена сводка атрибутов и базовых сервисов NT для
объектов—портов.
Описатели объектов—портов, в отличие от большинства других описате-
лей объек тов NT, нс могут наследоваться новыми процессами. Если бы наследо-
вание было разрешено, то серверу7 приходилось бы при получении каждого со-
общения определять, каким процессом оно послано. Поскольку наследование
запрещено, серверу заранее известно, каким процессом он вызван по данному
каналу, вследствие чего накладные расходы сервера снижаются и обслуживание
клиентов выполняется быстрее.
>1 WINDOWS NT
Тип объекта
рибуты тела объекта
Порт
Очередь сообщений
Описатель секций
Сервисы
Создать порт соединения
Открыть порт
Ожидать у порта
Установить/завершить соединение
Послать запрос
Ответить
Послать запрос и ждать ответа
Ответить и ждать ответа
Имперсонация клиента
с. 5-21. Объект-порт.
пособы передачи сообщений LPC
ри установлении канала связи с защищенной подсистемой клиент указывает;
кой из трех методов передачи сообщений LPC он желает использовать:
передача сообщений в очередь сообщений объекта—порта использует-
ся для сообщений малого размера;
В передача сообщений через объект-совместпо используемую память
используется для больших сообщений;
быстрый LPC используется исключительно компонентами подсистемы
Win32 для достижения минимальных накладных расходов и макси-
мальной скорости.
Эти три формы передачи сообщений и механизм обратного вызова рас-
латриваются в последующих подразделах.
опирование в порт
ервая и наиболее часто используемая форма передачи сообщений соединяет
1ресные пространства клиента и защищенной подсистемы, помещая клиент-
<ое сообщи 1ие в промежуточный бу фер с последующим копированием его оп-
/да в адресное пространство подсист емы. Промежуточным буфером здесь слу-
ит очередь сообщений объекта-порта связи.
Как показано на рис. 5-21, каждый объект-порт содержит очередь блоков
эобщений фиксированного размера. (Объекты—порты соединения содержат
чередь запросов на подсоединение, объекты—порты связи — очередь запросов
а обслуживание.) При посылке сообщения клиентом средство LPC помещает
-о в один из блоков сообщений объекта—порта подсистемы. После того, как
онтекст ядра NT переключится с клиентского процесса на процесс подсисте-
ы, поток последней копирует сообщение в адресное пространство подсистемы
Глава 5. Windows и защищенные подсистемы
Рис. 5-22. LPC с копированием сообщения.
и обрабатывает его. Когда ответ подсистемы готов, она посылает сообщение об-
ратно в порт связи клиента, как изображено на рис. 5—22.
В любой данный момент времени исполнительная система NT имеет доступ
либо к клиентскому адресному пространству, либо к адресному пространству под-
системы, но не к обоим сразу. Однако, как и другие объекты, объекты—порты
храня тся в системной памяти, так что при переключении контекста ядра NT с
клиентского процесса на процесс подсистемы доступ к сообщению пс теряется.
При создании процесса средство LPC выделяет память для пего из резидент-
ного пула, то есть из не откачиваемой на диск части системной памяти. Так как
резидентный пул — это конечный системный ресурс, то количество и размер бло-
ков сообщений в порту по необходимости ограничены. Размер блока сообщения
равен 256 байт, что достаточно дтя посылки большинства обычных сообщений.
S.5.2.2 Передача через совместно используемую память
Когда клиенту' нежно передавать сообщения, размер которых превышает 256 байт,
они не могут быть скопированы в очередь сообщений серверного объекта—порта.
Вместо этого клиент должен передавать их через объекты—совместно используе-
мую память, чьи размеры ограничены только ресурсными квотами клиента.
Для передачи сообщения через совместно используемую памятъ клиеггг со-
здает объект-совместно используемую память, называемый объектом—секцией
(section object). Объект-секция (более подробно огг описан в гл. 6, “Диспетчер вир-
туальной памяти”) — это блок совместно используемой памяти, который средство
LPC делает видимым в адресном пространстве как клиента, так и защищенной под-
системы12. Для посылки большого сообщения клиеггг помегцает его в объект-сек-
12 Средство LPC обращается к диспетчеру виртуальной памяти для двойного отображения секции в
оба адресных пространства. Для этого диспетчер виртуальной памяти использует совмещение вир-
туальных адресов, которое должно поддерживаться процессором.
[лава 5. Windows и защищенные подсистемы
I WINDOWS NT
ю, после чего посылает серверу меньшее сообщение, содержащее указатель и
»меры основного сообщения. После переключения контекста ядра NT на про-
:с подсистемы последняя выбирает информацию из блока сообщения и исполь-
гг ее для поиска сообщения в объекте-секции, как показано на рис. 5-23.
Обратите внимание, что перед установлением канала связи клиент должст i
ределить, будут ли его сообщения большими или маленькими. Если предпо-
гается, что сообщения будут невелики, то клиент не запрашивает выделение
ъекта—секции, но если хотя бы одно сообщение может быть большим, то
деление секции запрашивается. Как показано на рисунке, объект-секция свя-
н с портом связи клиента. Если ответы подсистемы также могут быть болыпн-
I, то она может создать объект-секцию, связанный с ее портом связи, где отвег-
,ie сообщения большого размера сохраняются перед отправкой их клиенту.
Использование объекта—секции требует от клиента некоторой дополни-
льной работы. Например, средство LPC не задаст какого—либо формата для
п>екта—секции, так что клиент должен самостоятельно управлять памятью к
ом объекте, сообщая подсистеме размер последнего сообщения и его место-
указатель
Рис. 5-23. LPC через совместно используемую память.
положение внутри секции. Необходимость дополнительного управления памя-
тью делает' передачу сообщений через совместно используемую память несколь-
ко более сложной (для клиента) в сравнении с посылкой сообщения непосред-
ственно в порт. Однако этот способ позволяет обрабатывать большие сообще-
ния без многократного копирования. Копирование большого объема данных из
одного адресного пространства в другое может быть медленной операцией, и
использование совместно используемой памяти помогает избежать этих на-
кладных расходов.
5.5.2.3 Обратные вызовы
Обычно у подсистемы имеется несколько, может быть, даже много, портов свя-
зи. Каждый из них служит каналом обмена информацией с одним клиентским
процессом. Для обслуживания запросов, которые она полу'част через свои пор-
ты, подсистема в общем случае создает набор потоков, ожидающих получения
сообщений и выполняющих их обработку'; каждый из потоков подсистемы мо-
жет обслужить любой запрос. Это обеспечивает большую гибкость для подсис-
темы, но требует от механизма LPC поддержания определенной схемы иденти-
фикации вызывающих клиентов и их сообщений, которая позволяла бы послать
ответ соответствующему' клиенту’ в соответствующий порт.
Чтобы отслеживать, каким клиентом послано сообщение, каждое из них
содержггг клиентский идентификатор вызывающего потока (атрибут каждого
обьекта—потока) и порядковый номер, присваиваемый сообщению средством
LPC. Когда подсистема отвечает на сообщение, она помещает в ответное сооб-
щение клиентский идентификатор потока, которому предназначен ответ, и по-
рядковый номер сообщения, ответом на которое является данное сообщение.
Средство LPC затем проверят; ожидает ли клиент с соответствующим иденти-
фикатором ответа на сообщение с указанным номером. Если нет; то LPC возвра-
щает код ошибки.
Иногда подсистема может’ оказаться неспособна сразу же послать ответ. Ей
можег понадобиться дополнительная информация от клиента. Для обработки
такой ситуации средство LPC предоставляет механизм обратных вызовов. Ти-
пичный пример обмена сообщениями показан на рис. 5-24 (сообщением об-
ратного вызова является шаг 2).
Обычно клиент посылает запрос и ожидает ответа. Однако если клиент
поддерживает обратные вызовы, то во время этого ожидания он может обраба-
тывать запросы от подсистемы. При помощи функций LPC клиент может отве-
тить па запрос и продолжать ожидание ответа на первоначальное сообщение.
Во многих ОС реализация обратных вызовов в средствах передачи сооб-
щений нс так гибка, как в исполнительной системе NT. Например, механизм об-
ратного вызова LPC NT полностью симметричен. Как сервер, так и клиент могут
выполнять обратные вызовы друг друта. Более того, средство LPC разрешает
любую вложенность обратных вызовов. Например, на шаге 3, изображенном на
рис. 5—24. вместо ответа на обратный вызов клиенту могло бы понадобиться
запросить у с е рвера дополнительную информацию, относящуюся к этому' об-
ратному вызову. В таком случае клиент послал бы серверу’ обратный вызов и стал
бы ожидать ответа как на свой обратный вызов, так и на первоначальный за-
прос. Другими словами, шаг 2 можег повторяться произвольное количество раз
как сервером, так и клиентом, при этом на обеих сторонах накапливались не-
обработанные обратные вызовы. Один за другим были бы получены ответы на
t
ВЫ WINDOWS NT
Рис. 5-24. Обратные вызовы.
Послать запрос на обслуживание_
и ждать ответа
Ответить запросом и ждать ответа _
(ОБРАТНЫЙ ВЫЗОВ)
Ответить на обратный вызов и ждать _
ответа на первоначальный запрос
Ответить на первоначальный запрос
каждый обратный вызов, пока не были бы обработаны все такие вызовы па обе-
их сторонах. После этого сервер, наконец, послал бы ответ на первоначальный
запрос клиента, и обмен сообщениями закончился.
Быстрый LPC
Как Вы, вероятно, и предполагали, Win32 — это сильно загруженная подсистема.
Так как она взаимодействует со всеми приложениями, выполняющимися в
Windows NT, у нее, вероятно, будет много клиентов одновременно. Данная под-
система могла стать “узким местом”, поэтому ее разработчики вместе с Марком
Лгоковски и Стивом Вудом реализовали быстрый LPC (quick LPC) — оптимизи-
рованный вариант передачи сообщений LPC, предназначенный для использова-
ния подсистемой Win32. Диспетчер окон и компонент GDI подсистемы Win32
применяют быстрый LPC для сокращения времени выполнения цикла “запрос-
ответ” при вызове клиентом сервера Win32.
Наибольший объем накладных расходов при передаче сообщения
приходится на открытие описателя объекта—порта гг копирование сообщений *’
очередь сообщений и из нее. Даже когда применяется LPC с совместно исполь-
зуемой памятью, клиент все равно посылает в очередь сообщение, которое до'1'
жно быть скопировано в адресное пространство подсистемы.
При использовании быстрого LPC клиентский поток посылает для усг"-*'
новления связи сообщение в серверный порт соединения, указывая, что хочС*
использовать быстрый LPC. В ответ сервер создаег для клиента три ресурса:
• выделенный серверный поток для обработки этого и последующ**''
запросов;
64 Кбайт совместно используемой памяти (объект—секция) для перед1*'
чи сообщений:
iaubu о. windows и защищенные подсистемы
* объект—пару событий.
После этого потоки сервера и клиента, использующие быстрый LPC, вооб-
ще не используют порт ы и передают сообщения друг другу через совместно ис-
пользуемую память. Объект-пара событий, который содержит- одно событие для
клиентского потока и одно для серверного, обеспечивает механизм неявной син-
хронизации. Например, клиент помещает сообщение в объект—секцию и уста-
навливает серверное событие, одновременно начиная ожидать свое собствен-
ное. Ядро NT пробуждает серверный поток, и, так как единственной задачей пос-
леднего является обслуживание одного клиентского потока, он сразу же знает,
где искать сообщение. Когда серверный поток заканчивает обработ ку сообще-
ния, он устанавливает событие клиента, одновременно начиная ожидать соб-
ственное событие. Взаимодействие продолжается аналогичным образом до тех
пор, пока не будет закрыто соединение быстрого LPC.
Устраняя накладные расходы, связанные с использованием объекта-порта
и копированием сообщений между двумя адресными пространствами, быстрый
LPC обеспечивает рост производительности для подсистемы Win32. Кроме того,
так как для обслуживания каждого клиентского потока создается выделенный
поток сервера, подсистеме не требуется при получении каждого сообщения
определять, каким клиентским потоком она вызвана. При использовании быс т-
рого LPC фактором, ограничивающим скорость передачи сообщений, становит-
ся время переключения контекста между клиентом и сервером (и наоборот). И
ядро NT минимизирует даже его. предоставляя этим потокам преимущество при
планировании потоков.
Так почему же использование быстрого LPC для передачи сообщений ог-
раничено только подсистемой Win32? Если он так быстр, почему не использо-
вать его для всех форм передачи сообщений в Windows NT? Ответ состоит в том,
что быстрый LPC устраняет одни накладные расходы за счет других. Что он
выигрывает в плане скорости, то теряется в использовании системных ресурсов.
LPC требует от- подсистемы, чтобы вместо набора потоков, которые могут обслу-
живать любое количество клиентов, она создавала отдельный серверный поток
для обслуживания каждого вызывающего ее клиентского потока. Мало того, что
расходуется сис темная память (в том числе из резидентного пула), но, к тому же,
эти выделенные потоки половину своего времени проводят в ожидании вызова
от клиента. Другим расходуемым ресурсом является объект—секция. В обычном
LPC каждый процесс может создать объект-секцию для передачи сообщений.
Если передачу-сообщений выполняют несколько потоков этого процесса, то все
они могут совместно использовать данную секцию. В быстром LPC у каждого
потока своя, отдельная сект 1я.
Эти накладные расходы в определенной степени снижаются благодаря
тому, что стеки потоков и память объекта—секции нерезидентны и могут при
необходимости откачиваться на диск. Однако использование быстрого LPC во
всех случаях было бы непрактичным. Он используется только диспетчером окон
и GDI подсистемы Win32. Компоненты консоли и ОС, равно как и все остальные
подсистемы Windows NT, применяют нормальный LPC.
Заключение
Модель клиент-сервер — одна из основ Windows NT и влияет не только на то.
как работает система, но и на то, как выполняются приложения. Первоначально
□на была выбрана потому, что ее гибкость позволяла реализовать в одной ОС Apj
как OS/2, так и POSIX, однако она также послужила фундаментом для защищен-
ной подсистемы Win32. Благодаря использованию этой модели приложения для
MS-DOS и 16-разрядной Windows могут мирно сосуществовать с приложения-
ми для Win32, OS/2 и POSIX, и все приложения могут передавать данные через
буфер обмена. Кроме того, модель клиент-сервер защищает друг от друга раз-
ные приложения, а также защищенные подсистемы от приложений.
В этой главе было описано, как выглядит Windows NT для пользователей
и прикладных программ. В следующей главе мы сделаем шаг вниз, обратно к
основам функционирования исполнительной системы NT, конкретно, диспет-
чера виртуальной памяти. Хотя разные подсистемы треды представляют па-
мять так, как этого ожидают их приложения, все они опираются на систему
виртуальной памяти исполнительной системы NT. Предметом следующей главы
будег диспетчер виртуальной памяти — компонент NT, предохраняющий при-
ложения и защищенные подсистемы от взаимных столкновений.
ДИСПЕТЧЕР ВИРТУАЛЬНОМ
ПАМЯТИ
Когда-то компьютеры были однозадачными, однопоточными системами. Про-
граммистам, опытным и начинающим, приходилось заранее записываться, что-
бы получить время для работы с единственной консолью компьютера. Роль ОС
исполнял сам программист: он должен был вручную загружать программу в па-
мять, используя переключатели, перфоленту или перфокарты. После того как
программа была загружена, он вводил начальный адрес и приказывал процессо-
ру перейти по этому адресу и начать выполнение. В те времена одновременная
загрузка и исполнение нескольких программ были невозможны. Не стоит и го-
ворить, что большая часть времени процессора терялась впустую.
Развитие технологии ОС сводилось к поиску того, как сделать процессор
занятым большую часть времени и, таким образом, выполнять больший объем
работы. Многозадачные ОС загружают в память несколько программ и поддер-
живают высокий уровень загрузки процессора, переключаясь между ними. Рас-
пределение всей доступной памяти между процессами и в то же время защита
кода и данных одного процесса от других и составляет задачу управления па-
мятью, а в случае Windows NT, управления виртуальной памятью (virtual me-
mory management).
На заре компьютерной эпохи не было возможности выполнять программу,
размер которой превышает объем физической памяти компьютера. Позже про-
граммисты стали писать оверлейные программы, которые выгружали одни час-
ти своего кода надиск и загружали другие в память. Когда программе требовался
код, находящийся на диске, она загружала его в память поверх ненужного в дан-
ный момент кода. Помимо того, что оверлейные программы было утомительно
писать и трудно сопровождать и модифицировать, в каждой программе нужно
было заново создавать код, выгружающий содержимое памяти па диск.
Виртуальная память, реализованная впервые в 1959 году', сняла бремя уп-
равления памятью с программиста и переложила его на ОС. Виртуальная па-
мять — эго централизованная система выгрузки на диск содержимого памяти
при переполнении последней. Она позволяет программистам создавать и за-
пускать программы, которые требуют памяти больше, чем есть v компьютера.
1 Компьютер Alius, разработанный примерно в |О5н году в Маичее!греком yiniBcpen'ieie. предоетав;
пял Biip'iva.'iMiyio память. Однако прошло не менее десяти .чет. прежде чем эта концепция получила
широкое рас проетранеиие с появлением (ХГ Mullics.
Виртуальная память стала с тандартным методом управления памятью для всех
ЭС, кроме простейших.
Компонент исполнительной системы NT, отвечающий за виртуальную па-
мять, диспетчер виртуальной памяти (virtual memory manager) — это базовая
система управления памятью в Window's NT. Любые возможности управления
замятью, предоставляемые подсистемами среды, основаны на средствах диспет-
тера виртуальной памяти. Последний разработан и реализован Лу Пераццолц,
соторый был также техническим руководителем проекта NT. Вместе с другими
менами команды Window's NT Лу сформулировал цели, поставленные перед
разработчиками диспетчера виртуальной памяти:
в Сделать его максимально переносимым.
Добиться, чтобы он работал надежно и эффективно для приложений
любых размеров и не требовал настройки пользователем или адми-
нистратором.
Обеспечить современные средства управления памятью, поддерживаю-
щие проецируемые файлы, память типа “копирование при записи”, а
также поддержку приложений, использующих большие, возможно, нс
непрерывные адресные пространства.
Обеспечить процессам возможность выделения и управления собствен-
ной памятью.
Обеспечить механизмы поддержки подсистем среды, в частности, по-
зволить подсистеме (имеющей соответствующие права доступа) управ-
лять виртуальной памятью клиентского процесса.
Достичь баланса между удовлетворением требований мультипроцессор-
ной обработки и скоростью доступа к памяти. (Например, защита струк-
тур данных с использованием нескольких уровней блокировки может
повысить степень параллелизма в диспетчере виртуальной памяти, но
каждая блокировка связана с дополнительными накладными расходами).
Следующий раздел начинается с введения в системы виртуальной памяти.
Цалее обсуждаются версия виртуальной памяти, используемая NT, — диспетчер
зиртуальной памяти — и дополнительные средства и возможности, предостав-
тяемые диспетчером виртуальной памяти подсистемам среды. Наконец, рас-
сматриваются особенности реализации диспетчера виртуальной памяти, вклю-
чая описание важнейших структур данных и алгоритмов.
Виртуальная память
амять можно описать в терминах: физической структуры, логической структу-
ры, а также способа, которым ОС транслирует (или не транслирует) одну сгруК-
гуру в другую.
Физическая память организована как последовательность однобайтовых
зчеек. Банты npoi |умеровапы от нуля и до общего размера памяти, доступной > в
данной конфшурации, минус 1. как показано на рис. 6-1. Этот набор чисел (но-
Адрес
Байтовое
содержимое
Рис. 6-1. Физическое адресное пространство.
казанных здесь в шестнадцатиричной системе счисления) составляет физичес-
кое адресное пространство машины2.
Логическая память, чаще называемая виртуальной (virtual memory) — это
способ представления памяти для программы, и в современных ОС она редко
совпадает с физической структурой памяти. Обычно системы виртуальной па-
мяти используют либо сегментное, либо линейное представление памяти. Во
всех первых персональных компьютерах на основе процессоров Intel, начиная
с Intel 8086 и заканчивая Intel 80286, была использована сегментная модель. В
системе сегментной адресации физическая память разделена на блоки адресов,
обычно последовательных, называемые сегментами. В типичном случае адрес
состоит из номера сегмента и смещения в сегменте.
С другой стороны, большинство процессоров RISC и даже последние
CISC—процессоры Intel поддерживают линейную структуру адресов. Линейная
адресация соответствует физической структуре памяти точнее, чем сегментная.
В линейной схеме адреса начинаются с 0 и возрастают, байт за байтом, до верх-
ней границы адресного пространства.
Виртуальное адресное пространство (virtual address space) — эго набор
адресов памя ти, которые могут использовать потоки процесса. Каждый процесс
имеет отдельное адресное пространство, которое обычно гораздо больше раз-
мера физической памяти. Хотя диапазон физических адресов для конкретного
( Л’ЩСС! В\Ю'1 КП.'ЖХ’ М.ППИПЫ. 1ДС СД11Н11ЦС1] 1К1МЯТП Я1С1ЯС'1СЯ СЛОВО. .! НС О31П. НО В ЭТОЙ 1.-I11BC р;1<
СМ.П pifH.HOICM 'iOJIl.bO nail F-opi К'||*П1роВ.!1 II |1>к* KOMIif.fO'lcpi.1
омпьютера ограничен объемом имеющейся у него памяти (каждый байт кото-
ой обладает уникальным адресом), диапазон виртуальных адресов ограничен
олько количеством битов в адресе. Каждый бит может быть либо установлен,
ибо сброшен; таким образом, например, процессор MIPS R4000, имеющий 32
азрядные адреса^, является счастливым обладателем виртуального адресного
ространства в 2-’-’, или 4 миллиарда байт (4 Гбайт), как показано на рис. 6-2.
ьдрес
Байтовое
содержимое
FFFFFFFh
FFFFFFFh
FFFFFFDh
FFFFFFCh
FFFFFF46
FFFFFF36
FFFFFF26
FFFFFFIh
ис. 6-2. Линейное виртуальное адресное пространство.
На самом деле MIPS R4000 предоставляет 6-1 разрядные адреса, по позволяет ОС использовать
ибо .32—, либо 64-разрядпыс адреса. Первая версия Windows NI использует 32—разрядные адреса
ля совместимости с Iniel ЗВ6.
Это несоответствие между физическим и виртуальным адресными про-
странствами приводит к тому, что система виртуальной памяти обязательно дол-
жна выполнять следующие две задачи:
ж Транслировать, или отображать (тар), некоторое подмножество вир-
туальных адресов каждого процесса в участки физической памяти. Ког-
да поток производит чтение или запись в своем виртуальном адресном
пространстве, система виртуальной памяти (часть которой может быть
реализована аппаратно) перед пересылкой данных определяет по вир-
туальному адресу соответствующий физический адрес.
Выгружать на диск часть содержимого памяти, когда она переполняет-
ся, т. е. когда потоки, выполняющиеся в системе, пытаются использовать
больше памяти, чем доступно физически.
Выполнение первой задачи — отображение виртуальных адресов в физи-
ческие — позволяет легко перемещать программу в памяти в ходе ее исполне-
ния. Система виртуальной памяти перемещает фрагменты программы на диск и
затем обратно в память, причем, возможно, по другим адресам. Затем она моди-
фицирует отображение логических адресов в физические, так чтобы оно указы-
вало на новое местоположение.
Вторая задача, выгрузка содержимого памяти на диск, является следствием
первой. Ясно, что процесс не может адресовать 4 Гбайт памяти, если в компью-
тере физически установлено только 4 Мбайт. Такой эффект достигается систе-
мой виртуальной памяти за счет использования диска в качестве резервной “па-
мяти”, называемой резервным хранилищем (backing store). При переполнении
физической памяти система виртуальной памяти определяет, какие данные
можно из нее удалить, и временно перемещает их в файл на диске. Когда эти
данные вновь потребуются выполняющемуся потоку, система виртуальной па-
мяти считывает их обратно с диска.
Перемещение данных между памятью и диском было бы недопустимо мед-
ленным, если бы диспетчер виртуальной памяти перемещал лишь по одному
байте за раз. Поэтому- виртуальное адресное пространство разделено на блоки
равного размера, которые называются страницами (pages). Соответственно,
физическое адресное пространство разделяется на блоки, называемые стра-
ничными фреймами (page frames), которые используются для хранения стра-
ниц. В любой момент времени в памяти находится некоторое множество стра-
ниц из виртуального адресного пространства каждого процесса. Страницы, на-
ходящиеся в физической памяти и доступные немедленно, называются действи-
тельными страницами (valid pages). Страницы, находящиеся на диске (или на-
ходящиеся в памяти, но не доступные немедленно), называются недействитель-
ными (invalid pages), как ясно из рис. 6-.3.
При обращении потока по виртуальному- адресу; который находится на
странице, помеченной как недействительная, процессор генерирует системную
ловушку, называемую страничной ошибкой (page fault). Система виртуальной
памяти находит нужную страницу на диске и загружает ее в свободный странич-
ный фрейм физической памяти. Когда число доступных страничных фреймов
становится мало, система виртуальной памяти выбирает фреймы, подлежащие
освобождению, и копирует их содержимое на диск Этот процесс, называемый
подкачкой страниц (paging), невидим прикладному программисту.
гуальное адресное Физическое адресное
6-3. Отображение виртуальных страниц в физические страничные фреймы.
Обработка страничной ошибки может быть дорогой операцией, требую-
i много тактов процессора. Однако большие размеры страницы снижают
>аты, так как в память загружается большее количество данных и страничные
тбки происходят реже. (Конечно, слишком большой размер страницы може т
вести к загрузке большего объема данных, чем необходимо, так что здесь
буется определенный баланс.) В общем случае число байт на странице выра-
гся степенью двойки и зачастую определяется аппаратурой. Windows NT ис-
ьзует размер страницы, установленный в Intel 386 и равный 212, или 4 Кбайт.
PS R4000 позволяет задавать размер страницы программно.)4
Хотя основные задачи системы виртуальной памяти — это отображение
туальных адресов в физические и пересылка данных между памятью и фопо-
। хранилищем, у нее есть и некоторые другие обязанности:
Я Обеспечивать легкий и эффективный способ совместного использова-
ния памяти двумя процессами.
Защищать как совместно используемую, так и “частную’' память от нссанк-
цнонироваьи юго доступа.
Если система предназначена для работы на многопроцессорном ком-
пьютере, как Windows NT, to она должна обрабатывать страничные
ошибки от нескольких потоков одновременно.
И нс yiCIXlHO ИНОС, ТО в ЭТОЙ 1ЛЛВС НПфорМаЦНЮ. относящуюся к Intel 586, можно считать вср-
цля совместимых с ним процессоров (например. AMD58O фирмы Advanced Micro Devices) ц г(дя
тио гопмсаимык процессоров find старших модс.чси (Intel 486).
1лава 6. Диспетчер виртуальной памяти
Способ выполнения этих задач системой виртуальной памяти исполни-
тельной системы NT — диспетчером виртуальной памяти — рассматривается в
следующих разделах данной главы.
6.2 Средства пользовательского режима
Базовые сервисы диспетчера виртуальной памяти NT обеспечивают процессам
пользовательского режима богатые возможности. Подсистемы среды использу-
ют эти сервисы для управления своими клиентскими процессами. Подсистема
Win32 также экспортирует некоторые из них в API Win32.
Диспетчер виртуальной памяти позволяет подсистемам пользовательского
режима эффективно совместно использовать память с помощью объектов, ко-
торые являются защищенными и именованными и управляются, как и другие
объекты исполнительной системы. Подсистемы могут постранично задавать
защиту персональной памяти и фиксировать в памяти выбранные страницы.
Они могут также использовать проецируемые файлы и управлять виртуальными
адресными пространствами своих клиентов.
Следующие подразделы рассматривают средства, предоставляемые дис-
петчером виртуальной памяти пользовательскому режиму: управление вирту-
альным адресным пространством процесса, совместное использование памяти
процессами и защиту’ виртуальной памяти процесса от других процессов.
6.2.1 Управление памятью
Как показано на схеме атрибутов и сервисов объекта—процесса из гл. 4, “Про-
цессы и потоки” (рис. 4-3), диспетчер виртуальной памяти предоставляет набор
базовых сервисов, при помощи которых процесс может напрямую управлять
своей виртуальной памятью. Эти сервисы позволяют процессу7:
выделять память в два этапа;
В выполнять чтение и запись в виртуальную память;
В фиксировать виртуальные страницы в физической памяти;
s получать информацию о виртуальных страницах;
* защищать виртуальные страницы;
* сбрасывать содержимое виртуальных страниц на диск
Диспетчер виртуальной памяти устанавливае т двухфазный способ выделе-
ния памяти — резервирование памяти, а затем ее передача. Зарезервированная
намять (reserved memory) — это набор виртуальных адресов, которые диспет-
чер виртуальной памяти зарезервировал для использования процессом. В
Windows NT резервирование памяти (т. е. виртуальных адресов) — это быстрая
и дешевая операция. Переданной памятью (committed memory) называется па-
мять, для которой диспетчер виртуальной памяти выделил место в файле под-
качки (paging file) дисковом файле, в который он записывает виртуальные
страницы, когда их надо удалить из памяти. Поток може т либо сразу зарезерви-
ровать и передать виртуальную память, либо вначале лишь зарезервировать ее,
передавая по мере необходимости.
Резервирование памяти полезно при создании динамических структур дац-
1ых. Поток резервирует последовательные виртуальные адреса, передавая цх
согда возникает необходимость поместить по ним данные. Если нужно увели,
тить размер структуры данных, то поток может передать дополнительную ца.
пять из зарезервированного региона. Такая стратегия гарантирует, что другой
тоток этого процесса (например, библиотечный пакет) или другой процесс
например, поток подсистемы Win32) не сможет занять последовательные вир.
гуальные адреса, которые могут понадобиться для расширения структуры да1ь
гых. Поток может либо задать начальный виртуальный адрес резервируемого
эегиона, либо позволить диспетчеру виртуальной памяти самому найти для него
песто в виртуальном адресном пространстве соответствующего процесса.
Диспетчер виртуальной памяти списывает с процесса часть его квоты и
]зайлс подкачки при передаче, но не при резервировании памяти. Такая двух-
уровневая семантика позволяет потоку зарезервировать большой регион вирту-
1льной памяти, но не расходовать квоту до тех пор, пока эта память действи-
тельно не понадобится. Она также позволяет сохранить место в файле подкачки
1ля страниц, которые на самом деле используются. Если некоторый диапазон
адресов более не используется, то поток может его “передать обратно”, осво-
бождая пространство в файле подкачки и восстанавливая квоту процесса (под-
робнее о квотах процесса см. гл. 4, “Процессы и потоки”).
Для приложений, работающих в реальном времени или предъявляющих
лные требования к производительности, диспетчер виртуальной памяти позво-
1яст подсистеме пользовательского режима или другому процессу с соответ-
ствующими привилегиями фиксировать в памяти выбранные виртуальные стра-
тицы. Это гарантирует, что критическая страница не будет удалена из памяти до
гех пор, пока в процессе выполняется хотя бы один поток Например, приложе-
тие базы данных, хранящее свою информацию в виде структуры-дерева, может
зафиксировать в памяти корень дерева, чтобы доступ к базе данных не вызывал
дополнительных страничных ошибок.
Как и другие сервисы NT, сервисы виртуальной памяти позволяют вызыва-
вшему их передать описатель процесса, чтобы учсазагь, с виртуальной памятью
<акого процесса следует работать. Вызывающий процесс может манипулнро-
зать как своей виртуальной памятью, так и памятью другого процесса. Это мот-
тое средство, так как оно позволяет процессу пользовательского режима управ-
1ять адресным пространством другого процесса. Например, процесс может со-
здать новый процесс, предоставив себе право работать с его адресным про-
странством. После этого первый процесс може т выделять и освобождать память.
1 также выполнять чтение и запись в нее для второго процесса, вызывая сервисы
зиртуальной памяти и передавая им описатель последнего. Подсистемы исполь-
зуют данное средство для управления памятью их клиентских процессов.
Приложения Win32 имеют дос туп ко многим возможностям диспе тчер:*
зиртуальной памяти посредст вом API Win32. Они могут выделять и освобождать
зиртуальную память, производить се чтение и запись в нес. сбрасывать содержи-
мое виртуальных страниц па диск, получать информацию о диапазоне вирту-
зльных страниц, фиксировать виртуальные страницы в памяти и защищать за-
данные страницы. Однако пи одна нз этих функций API не позволяет приложе-
нию Win32 “залезать” в виртуальную память другого процесса, за исключение'*
функций ReadProcessMcmoryO и WritcProcessMemory(). Они используются от-
гадчиками пользовательского режима для установки точек останова и нолече-
гня информации об отлаживаемом процессе.
£.2-2 Совместное использование памяти
Важная задача любой системы управления памятью — обеспечить возможность
совместного использования памяти двумя процессами, если им эго необходимо
или если это может повысить эффективность функционирования ОС. Напри-
мер, когда два процесса выполняют компиляцию программы на С, можно сэко-
номить память, если загружать в нее только одну копию компилятора. (Конечно,
каждому процессу также нужна персональная память для хранения собственных
данных и кода.)
Виртуальная память предоставляет удобный механизм совместного ис-
пользования памяти. Так как у каждого процесса есть отдельное адресное про-
странство. ОС достаточно загрузить компилятор только один раз, и, когда он
будет вызван другим процессом, диспетчер виртуальной памяти просто отобра-
зит виртуальные адреса этого процесса на физические страничные фреймы, в
которых уже находится компилятор (см. рис. 6—4).
Аналогично, если два взаимодействующих процесса создают совместно
используемый бу фер памяти, то виртуальное адресное пространство каждого из
них может быть отображено на одни и те же физические страничные фреймы,
занятые буфером. В примере с компилятором диспетчер виртуальной памяти не
позволяет ни одному' процессу- изменять страницы, занятые компилятором. В
обоих процессах соответствующие виртуальные страницы помечаются “только
для чтения”. Однако в случае с буфером возможность записи в него может по-
требоваться потокам обоих процессов. Следовательно, страницы помечаются
признаком “чтение/запись”. Конечно, при таком совместном использовании
структур данных необходимо синхронизировать доступ потоков к совместно
используемой памяти, чтобы предотвратить одновременный их доступ и по-
вреждение данных (защита памяти описана в разд. 6.2.3).
Подсистема Win32 обеспечивает приложениям Win32 доступ к средствам
совместного использования памяти исполнительной системы NT при помощи
функций API для проецирования файлов, что и обсуждается в следующем разделе.
6.2.2.1 Секции, проекции и проецируемые файлы
Как и все остальные компоненты Windows NT, диспетчер виртуальной памяти
является полностью параллельным. Он выполняется одновременно на всех про-
цессорах многопроцессорного компьютера, и его структуры данных совместно
используются потоками, выполняющимися на разных процессорах. Таким обра-
зом, создание эффективного решения для совместного использования памяти в
Windows NT важно не только для программ пользовательского режима, но и для
самой системы.
Совместно используемую намять (shared memory) можно определить как
память, видимую более чем одним процессом и присутствующую в нескольких
виртуальных адресных пространствах. Подход Windows NT к совместному ис-
пользованию ресурсов состоит в том, что они реализуются в виде защищенных
объектов, и память не является исключением. Объект-секция (section object),
который подсист ема Win32 делае т доступным для своих клиентов как объект
проекцию файла (file mapping object), представляет собой блок памяти, совмест-
но используемый двумя или более процессами. Поток одного из процессов со-
здаст объект-секцию и присваивает ему имя, чтобы потоки других процессов
могли открыть его описатели. Открыв описатель объекта—секции, поток может
WINDOWS NT
тобразить секцию целиком или частично в виртуальное адресное простран,
тво, свое собственное или другого процесса.
Объект—секция NT может быть довольно большим и занимать десятки, сот-
м, даже тысячи страниц. Для экономии своего виртуального адресного про.
транства процесс может отобразить только нужную ему часть секции; эта ото-
раженная часть называется проекцией (view) секции. Проекция служит окном R
овместно используемую область памяти, и разные процессы могут отображать
азные проекции секции или даже несколько проекций, как показано на рис. 6-5
Проекции секции позволяют процессу работать с большими блоками на-
йти, для отображения которых целиком у него может не хватить виртуального
дресного пространства. Например, у фирмы может быть большая база данных
информацией о ее сотрудниках. Программа базы данных создает объект-сек-
иртуальная память
процесса 1
:. 6-4. Совместное использование памяти.
цию, содержащий эту базу целиком. При обработке запроса к базе данных про-
грамма отображаег проекцию секции с базой данных, считывает данные в свое
адресное пространство, убирает отображение проекции, после чего отображает
новую проекцию секции. Программа как бы перемещает “окно” по этой боль-
шой секции, считывая данные из всех частей базы и не переполняя при этом
свое виртуальное адресное пространство.
Как и в случае собственной памяти, содержимое совместно используемой
памяти откачивается на диск, когда физической памяти становится недостаточ-
но. При удалении из памят! i большинства страниц, как совместно используемых,
Виртуальная память
процесса 1
Рис. 6-5. Отображение проекций секции.
так и нет, диспетчер виртуальной памяти записывает их в файл подкачки. Одца
ко объект-секция может откачиваться и в проецируемый файл (mapped filq
Примером такого файла является база данных сотрудников фирмы. Программ’ '
базы данных использует объект-секцию для переноса содержимого файла .
виртуальную память. Затем она может работать с файлом как с большим млссц.
вом, отображая различные проекции секции и производя чтение и запись в tJa
мять, а не в файл. Этот процесс называется также проекционным файловым ав()
дом-выводом (mapped file I/O). Когда программа обращается к недействитедь.
ной странице (к такой, которая не находится в физической памяти), проиехц. '
дит страничная ошибка, и диспетчер виртуальной памяти автоматически пере,
мещает эту страницу из проецируемого файла в память. Если приложение модц.
фицировало страницу; то диспетчер виртуальной памяти записывает изменеццд •
обратно на диск в процессе обычной откачки страниц.
11сполнитсльная система NT использует проецируемые файлы для загрузки в
память исполняемых образов, а системный диспетчер кэша — для чтения и записи
кэшируемых страниц. Система ввода-вывода использует проецирование файле®
при обработке запросов ввода-вывода, предоставляя диспетчеру виртуальной па-
мяти выполнять запись изменений на диск в процессе обычной откачки страниц. ’
Для приложений Win32 проецируемые файлы служат удобным способом
прямого (в дополнение к последовательному7) доступа к большим файлам. При-
ложение создает для файла объект-проекцию файла Win32 (соответствующий •
объекту-секции NT), после чего выполняет чтение и запись по произвольным
смещениям внутри файла. Диспетчер виртуальной памяти автоматически подка-
чивает нужные порции файла и записывает изменения обратно на диск
Объект-секция
Объекты-секции, подобно другим объектам, создаются и удаляются дне- •
петчером объектов. Последний создает и инициализирует заголовок объекта,
который используется для управления объектами; диспетчер виртуальной памя-
ти определяет тело объекта—секции. Кроме того, диспетчер виртуальной памяти
предоставляе т сервисы, которые могут вызываться потоками пользовательского
Тип объекта
Секция
Атрибуты тела объекта
Сервисы
Максимальный размер
Защита страниц
Файл подкечки/проецируемый файл
Базированнся/не базированная
Создать секцию
Открыть секцию
Расширить секцию
Отобразить/удалить проекцию
Запросить информацию секции
Рис. 6-6. Объект -секция.
режима для считывания и изменения значений атрибутов, хранящихся в теле
объекта-секции. Объект-секция показан на рис. 6-6.
В табл. 6-1 перечислены атрибуты, специфичные для объекта-секции.
Таблица 6-1. Атрибуты объекта-секции
Атрибут Назначение
Максималы 1ый размер Максимальное число байт, до кот орого может расти размер секции; в случае проецируемого файла равно размеру файла
Защита страниц Постраничная защита памяти назначается всем страницам секции при ее создании
Файл подкачки/ проецируемый файл Указывает, создана ли секция пустой (резервное хранилище — файл подкачки) или загружена из файла (резервное хранилище — проецируемый файл)
Базированная/не базированная Указывает, является ли секция базированной (которая долж- на располагаться по одному и тому же виртуальному адресу во всех использующих ее процессах) или не базированной секцией, которая в разных процессах может располагаться по разным виртуальным адресам
Отображение проекции секции делает часть секции видимой в виртуаль-
ном адресном пространстве некоторого процесса. Аналогично, удаление проек-
ции секции удаляет ее из адресного пространства процесса.
Совместное использование имеет место, когда два процесса отображают
в свои адресные пространства фрагменты одной и той же секции. В этом слу-
чае процессы должны синхронизировать доступ к секции, чтобы избежать од-
новременного изменения данных. Для синхронизации можно использовать
события, семафоры или аппаратно—зависимые блокировки. Сами по себе
объекты—секции не являются синхронизационными объектами, т. е. поток не
может синхронизировать свое выполнение, ожидая у описателя секции. При-
ложения Win32 для синхронизации доступа к объекту-проекции файла (их
эквиваленту объекта—секции) могут использовать мьютексы, события, семафо-
ры или критические секции.
Для того, чтобы отобразить проекцию секции, процесс сначала должен
получить ее описатель. У процесса, создавшего секцию, этот описатель уже есть.
Другие процессы (с соответствующими правами доступа) могут открыть описа-
тели объекта—секции, если у этого объекта есть имя. Кроме того, процесс может
получить описатель секции при наследовании, или когда другой процесс дубли-
рует свой описатель объекта-секции и передает его процессу-реципиенту. Во
всех описанных случаях и имеет место совместное использование памяти. Если
совместно используемая секция создана как временный объект, то диспетчер
объектов удаляет эту память, когда освобождается последняя ссылка на объект-
секцию. Постоянные объекты—секции не удаляются.
6.2.3 Защита памяти
В Windows NT существует че тыре формы защиты памяти. Первые три встреча-
ются в большинстве современных ОС:
* Отдельное адресное пространство для каждого процесса Аппаратура нс
позволяет потоку обращаться по виртуальным адресам другого процесса.
40
Два режима работы: режим ядра, в котором потоки имеют доступ к си-
стемному коду' и данным, и пользовательский режим, потоки которого
такого доступа не имеют.
Механизм постраничной защиты. С каждой виртуальной страницей
связан набор флажков, определяющий, какие типы доступа к ней разре-
шены в пользовательском режиме и в режиме ядра.
Следующий механизм, уникальный для Windows NT, обеспечивает еще
ну форму защиты памяти:
Пообъектная защита памяти. Всякий раз, когда процесс открывает опи-
сатель объекта—секции или отображает проекцию секции, справочный
монитор защиты Windows NT проверяет, имеет ли процесс, пытающий-
ся выполнить операцию, соответствующие права доступа.
В следующих подразделах рассмотрены два типа защиты памяти, поддер-
1ваемые этими механизмами, — защита собственной памяти процесса и защи-
совместно используемой памяти.
эбственная память процесса
:який раз, когда поток обращается по виртуальному адресу, диспетчер вирту-
ьной памяти исполнительной системы NT и аппаратура вмешиваются и транс-
[руют этот адрес в физический. Управляя трансляцией виртуальных адресов,
1стема виртуальной памяти трантирует, что потоки одного процесса не полу-
т доступа к страничному фрейму, принадлежащему другому процессу.
Помимо косвенной защиты за счет трансляции виртуального адреса в
тзический, калщый процессор, поддерживающий виртуальную память, обеспс-
1вает некоторую форму' аппаратной защиты памяти. Однако формы защиты и
: аппаратная реализация на разных процессорах различны. Аппаратная защи-
зачастую минимальна, и ее требуется дополнить механизмами, предоставля-
|ыми программным обеспечением виртуальной памяти. Из-за этого диспст-
р виртуальной памяти Windows NT сильнее зависит от аппаратных особенно-
ей, чем другие части системы.
Аппаратная страничная защита действует при всяком обращении потока к
мяти. Например, на процессоре MIPS R4000 каждая страница виртуальной па-
пы — это либо страница пользовательского режима (нижние 2 Гбайт), либо
раницей режима ядра (верхние 2 Гбайт); она также имеет признак ‘ только
ение” либо “чтение/запись”. Если поток исполняется в режиме ядра, то про-
ссор позволяет ему читать любую действительную страницу памяти и изли-
ть действительные страницы с признаком “чтспис/запись”. В пользователь»-
м режиме поток может обращаться только к действительным страницам
шьзовательского режима и модифицировать тс из них, ко торые имеют при
ак “ччснис/запись”. MIPS R4000 генерирует страничную ошибку при обрате
in к недействительной (отсутствующей в памяти) странице. При попытке чае-
1я или записи действительной ст раницы с нарушением описанных выше нра
л он генерирует исключение адресной ошибки (нарушение доступа).
Аппаратура может контролировать доступ только для действительных
раииц — тех. которые присутствуют в памяти. Если поток обращается к иедей
вителыюп странице (той, которой в памяти нет), MIPS R4000 генерирует с гра
яичную ошибку и в дело вступает программ! ioe обеспечение подкачки страниц
диспетчера виртуальной памяти.
Диспетчер виртуальной памяти обеспечивает тс же виды защиты, которые
MIPS R4000 предоставляет для действительных страниц:
й только чтение;
® чтение/запись;
а также предоставляет несколько собственных:
только исполнение (если есть аппаратная поддержка);
сторожевая страница;
нет доступа;
копирование при записи.
Используя базовые сервисы виртуальной памяти, подсистема среды может
управлять страничной защитой личных страниц. Управление защитой страниц
может повысить надежность программ, гарантируя, что потоки не модифициру-
ют страницы “только для чтения”. Эта возможность также полезна, например,
при отладке многопоточной программы, один из потоков которой выполняет
ошибочную запись в память. Временно изменив защиту соответствующей стра-
ницы на “только ч тение” или “нет доступа”, отладчик может перехватить невер-
ную операцию потока и локализовать ошибку.
Поток не может выполнять ни чтение, ни запись страницы “только испол-
нение”, однако он может перейти по адресу на этой странице и начать выполне-
ние. Этот тип защиты подходит для совместно используемого кода приложения,
например редактора или компилятора. Все потоки должны иметь возможность
выполнения данного кода, но никто не должен иметь права читать или изменять
исполняемый образ. (Обратите внимание, что ни MIPS R4000, ни Intel 386 или
486 не поддерживают такой тип защиты. Таким образом, на этих процессорах
доступ для исполнения эквивалентен доступу “только для чтения”.)
Диспетчер виртуальной памяти предоставляет защиту' сторожевых стра-
ниц для поддержки автоматической проверки переполнения стека. Однако этот
тип защиты может также использоваться и для обозначения границ других
структур. Когда поток обращается к сторожевой странице, диспетчер виртуаль-
ной памяти генерирует исключение сторожевой страницы, и поток получает
уведомление о том, что была затронута такая страница. Затем диспетчер вирту-
альной памяти позволяет продолжить операцию, вызвавшую это исключение.
Если подсистема или другое приложение поместит сторожевую страницу, на-
пример, в конце динамического массива, то при обращении к этой странице
подсистема получит предупреждение и сможе т динамически расширить массив.
Защита страницы “нет доступа” используется, чтобы предотвратить чтение
или запись данной страницы. При доступе к такой странице диспетчер вирту-
альной памяти кнерирует исключение. Он назначает такой тип защиты страни-
цам, к<люрые не были выделены или были зарезервированы, но не переданы.
Тип защиты “нет доступа” используется в основном отладчиками.
Подсистема Win32 обеспечивает приложениям Win32 доступ к средствам
защиты страниц диспетчера виртуальной памяти посредством функции API
VirtualProtcct(). Эта функция позволяет приложениям помечать виртуальные
ЗЫ WINDOWS NT
"границы как “только для чтения”, “чтение/запись” или “нет доступа”. Не обеспс-
швается защита вида “сторожевая страница”, “только исполнение” и “копирова-
те при записи”*.
Совместно используемая память
Гип защиты страниц “копирование при записи”, упоминавшийся в предыду.
дем разделе, — это средство оптимизации, которое диспетчер виртуальной
тамяти использует для экономии памяти. Если два процесса желают читать и
изменять содержимое одной и той же области памяти (но не использовать его
совместно), диспетчер виртуальной памяти назначает этой области защиту,
‘копирование при записи”. Затем оба процесса совместно используют эту об-
тасть памяти до тех пор, пока ни один из них не пишет в нее. Если поток од-
ого из процессов модифицирует страницу этой области, диспетчер виртуаль-
ной памяти копирует физический страничный фрейм в другое место памяти
модифицирует виртуальное адресное пространство процесса, чтобы оно ука-
зывало на копию, и назначает новой странице защиту “чтение/запись”. Как
показано на рис. 6-7, скопированная страница невидима потокам других про-
Виртуальная память
процесса 1
Рис. 6-7. Защита “копирование при записи".
* Согласно описанию функции VinuaiProtcciC). приведенному в справочной системе Win32 API. о11*1
ноЛЗсржнвист все виды зииипы.
цессов. Таким образом, поток может изменять свою копию страницы, не затра-
гивая других использующих ее процессов.
Защита “копирование при записи” важна для страниц, содержащих код;
она гарантирует, что изменение исполняемого образа затронет только тот про-
цесс, чей поток выполнил это изменение. Например, первоначально страницы
кода помечаются как “только исполнение”. Однако, если в процессе отладки
программист задает точку останова, то отладчик должен поместить в код соот-
ветствующую машинную команду. Для этого отладчик сначала изменяет защиту'
страницы на “копирование при записи”. Диспетчер виртуальной памяти немед-
ленно создает отдельную копию страницы для процесса, чей поток устанавлива-
ет точку останова. Остальные процессы продолжают использовать неизменен-
ный вариант кода. Подсистема Win32 не позволяет приложениям непосред-
ственно использовать защиту вида “копирование при записи”, однако косвен-
ным образом использует ее, ч тобы предоставить процессу от дельный экземпляр
данных в DLL и для других целей'.
Защита страниц типа “копирование при записи” — это один из примеров
применения способа оптимизации, называемого отложенным вычислением
(lazy evaluation), который используется диспетчером виртуальной памяти везде,
где эго возможно. Алгоритмы отложенного вычисления стараются не выпол-
нять “дорогостоящих” операций до тех пор, пока это не станет абсолютно необ-
ходимым. Если операция так никогда и нс потребуется, то на нее н нс будет
потрачено времш пь Огромные преимущества от такой оптимизации получает
подсистема POSIX. Обычно, когда в оригинальной системе POS1X процесс вызы-
вает функцию fork() для создания другого процесса, ОС копирует все содержи-
мое адресного пространства старого процесса в адресное пространство нового,
что требует больших затрат времени. Часто новый процесс сразу же вызывает
функцию ехес(), которая заново инициализирует его адресное пространство
соответствующей исполняемой программой, что делает предыдущую операцию
копирования напрасной. В противоположность этому, алгоритм отложенного
вычисления, используемый диспетчером виртуальной памяти, просто назначает
страницам адресного пространс тва родительского процесса защиту “копирова-
ние при записи” и обеспечивает их совместное использование родителем и
потомком. Если дочернин (или родительский) процесс никогда не выполняет
запись в свое адресное пространство, то оба процесса продолжают использо-
вать страницы совместно, и копирование не производится. Если же один из них
все—таки выполняет запись, то диспетчер виртуальной памяти копирует только
измененные страницы, а нс целиком все адресное пространство.
Все описанные выше механизмы защиты памяти реализованы либо аппа-
ратно. либо низкоуровневым программным обеспечением управления памятью,
которое вызывается всякий раз, когда поток обращается по определенному ад-
ресу. Объектная архитектура Windows NT предоставляет, кроме того, дополни-
тельный уровень защиты для памяти, совместно используемой несколькими
процессами. Подсистема защиты охраняет объекты-секции тем же способом,
каким она эго делает для других объектов исполнительной системы —- исполь-
зуя списки контроля доступа (ACL) (см. гл. 3, “Диспетчер объектов и контроль
дос тупа”). Поток может создать объект—секцию, ACL которого определяет, какие
В оригинале неточность. Данный тин зашиты доступен приложениям нсноерсдстненно.
Ы WINDOWS NT
ользователи или группы пользователей могут выполнять запись или чтение
екции, получать информацию о ней или увеличивать ее размер.
Справочный монитор защиты проверяет защиту объекта-секции всякий
1аз, когда поток открывает описатель секции или отображает ее проекцию. Если
CL не разрешает выполнение операции, то диспетчер объектов отвергает вы.
ов. После того, как поток успешно открыл описатель, его действия по-прежие-
iy контролируются механизмами защиты страниц, описанными выше.
Поток можег изменять страничную защиту виртуальных ст раниц секции
олько в том случае, если это изменение нс нарушает прав, определенных в Асу
)бьекта-секции. Например, диспетчер виртуальной памяти позволяет потоку
изменить защиту страниц секции, к которой поток имеет доступ “только чте-
ние”, на “копирование при записи”, но не на “чтение/запись”. Изменение защи-
ты на “копирование при записи” разрешено, так как не оказывает влияния на
другие процессы, использующие данные в этой секции.
Контроль прав доступа осуществляется и тогда, когда поток создает сек-
цию для проецируемого файла. Чтобы сделать это, поток должен иметь соответ-
ствующий доступ к файловому объекту. Например, поток, создающий секцию
для проецирования файла, должен иметь по крайней мере доступ по чтению к
данному' файлу. После того, как файл загружен в секцию, поток может изменять
ACL объекта-секции только в тех пределах, которые установлены ACL файла.
Реализация виртуальной памяти
До этого мы рассматривали основные принципы виртуальной памяти н сред-
ства пользовательского режима, предоставляемые диспетчером виртуальной
памяти исполнительной системы NT. Следующие подразделы посвящены внут-
ренним вопросам — структурам данных и алгоритмам, которые невидимы коду
пользовательского режима, но оказывают влияние на работу и производитель-
ность виртуальной памяти. Сначала описывается структура виртуального адрес-
ного пространства процесса, далее объясняются механизмы подкачки страниц
и правила, в соответствии с которыми процесс использует память. Затем приво-
дится краткое описание двух основных структур данных, используемых компо-
нентами виртуальной памяти. В заключение рассматриваются общие вопросы
мультипроцессорной обработки и переносимости системы виртуальной памяти
Адресное пространство
Каждому процессу’ в NT предоставляется большое виртуальное адресное про-
странство размером 4 Гбайт, из которых 2. Гбайт зарезервированы для использо-
вания системой5. Нижняя половина виртуального адресного пространства дос-
тупна потокам пользовательской) режима и режима ядра и уникальна для каж-
дого процесса. Верхняя половина доступна только потокам режима ядра и для
всех процессов одинакова. Виртуальное адресное прост ранст во процесса изоб-
ражено на рис. 6-8.
' Процессор MIPS КЮ(Х> требует. "либы - Гбайт были зарезервированы за системой. Друтс процессор1,1
qx-бугп меньшего объема, но для обеспечения переносимости системы 2 Гбайт резервируются всегда.
lACjBCI О. ДИС1 Ю1ЧИPipiyUAbi-HJH iiuiuihivi
FFFFFFFFh
COOOOOOOh
8000000011
OOOOOOOOh
Резидентная
Нерезидентная
Непосредственно
отображаемые
адреса
Нерезидентная
Системная память
(2 Гбайт)
Пользовательская память
(2 Гбайт)
Рис. 6-8. Виртуальное адресное пространство.
Код п данные ядра расположены в нижней части системной памяти (от
8000000011 до BFFFFFFF11 на MIPS R4000) и никогда не откачиваются на диск. На
MIPS R4000 эта область памяти непосредственно отображается аппаратурой.
Это означает, что процессор обнуляет три самых старших бита любого вирту-
ального адреса в данном диапазоне и использует остальные биты как физичес-
кий адрес (в результате эти данные помещаются в нижние адреса физической
памяти). Так как адреса из этого диапазона отображаются аппаратно и всегда
действительны, обращение к данному регион)' памяти выполняется очень быст -
ро. В нем размещаются части ядра, которым требуется максимальная произво-
дительность, например, код, направляющий потоки на исполнение.
Верхняя часть системной памяти управляется диспетчером виртуальной
памяти и используется для хранения другого системного кода и данных. Часть
этой области выделена для кода и данных, которые можно откачивать на диск, а
другая часть — для кода и данных, которые постоянно являются резидентными
(например, для кода, выполняющего подкачку страниц).
При создании процесса диспетчер виртуальной памяти может инициали-
зировать его адресное пространство либо копией адресного пространства дру-
гого процесса, либо проекцией файла. В частности, подсистема POSIX использу-
ет первый метод, когда один из ее клиентов создает дочерний процесс. Адресное
пространство дочернего процесса есть копия родительского процесса (на са-
мом деле родитель и потомок совместно используют страницы типа “копирова-
ние при записи”, так что при создании потомка копирование не выполняется
немедленно). Второй метод используется при создании нового процесса для
выполнения исполняемого файла. Например, когда пользователь запускает ути-
литу chkdsk, диспетчер процессов NT создаст- процесс, а диспетчер виртуальной
памяти инициализирует адресное пространство этого процесса исполняемым
образом chkdsk, который затем выполняется.
Подсистемы среды могут представлять своим клиентам память в виде, нс
совпадающем со схемой адресного пространства базового процесса NT. Вирту-
альное адресное пространство приложений Win32 идентично адресному про-
странству базового процесса, однако подсистема OS/2 и виртуальные DOS-ма-
шины (VDM) представляют своим клиентам память иначе.
ВЫ WINDOWS NT
Подкачка страниц
Зачастую, чтобы раскрыть внутреннее устройство компонента ОС, достаточна
задать два важных вопроса:
• Какие механизмы использует этот компонент для выполнения своей
задачи?
» Какой стратегии подчиняются эти механизмы?
В состав механизмов виртуальной памяти входят способ, которым диспег-
чер виртуальной памяти транслирует виртуальные адреса в физические, и спо-
соб перемещения страниц в физическую память. Стратегия же виртуальной па-
мяти, наоборот, определяет, к примеру, когда и в какое место памяти должна
быть загружена страница.
Часто процессор предоставляет примитивные механизмы подкачки стра-
ни! и которые дополняет система виртуальной памяти. Средство подкачки (pager),
код диспетчера виртуальной памяти, перемещающий страницы между памятью
и диском, является важным промежуточным звеном между аппаратными меха-
низмами и стратегией, определяемой программными средствами:
в Когда происходит страничная ошибка, оно делает недействительную
страницу7 дейсгвительной (например, путем загрузки ее с диска).
ж Оно обеспечивает страничную защиту для недействительных страниц
и расширяет аппаратные возможности защиты действительных.
* Оно поддерживает и обновляет структуры данных управления памятью.
Помимо этого, средство подкачки обеспечивает выполнение стратегии под-
качки, определяемой диспетчером виртуальной памяти. Следующий подраздел опи-
сывает механизмы виртуальной памяти, предоставляемые MIPS R4000. За ним вдет
подраздел, посвященный стратегии подкачки диспетчера виртуальной памяти.
Механизмы подкачки страниц
Все процессоры, которые поддерживают виртуальную память, делают это по-
разному. Таким образом, код, непосредственно работающий с аппаратным
обеспечением виртуальной памяти, не является переносимым, и его приходит -
ся изменять для каждой новой аппаратной платформы. В лучшем случае, как в
Windows NT, этот код невелик и хорошо изолирован.
Информация из данного раздела специфична для MIPS R4000 и являет со-
бой пример взаимодейсгвия между диспетчером виртуальной памят и и процес-
сором. Большая часть этой информации применима и для CISC-процессоров
Intel, но для простоты процессоры Intel здесь подробно не обсуждаются.
MIPS R4000 содержит два модуля: 32-разрядный RISC, блок вычислений
(называемый СР1) и отдельный модуль, выполняющий трансляцию адресов и
обработку исключений (СЮ). СТО автоматически перехватывает любой исполь-
зуемый программой адрес и транслирует его в физический адрес. Если страни-
ца, содержащая адрес, является действительной (находится в памяти), то СРО
аходит ее и считывает информацию. Если страница недействительна (отсут-
ствует в памяти), то СРО генерирует страничную ошибку; и вызывается средство
подкачки диспетчера виртуальной памяти.
Глава 6. Диспетчер виртуальной памяти
Совпадение
Рис. 6-9. Обращение к справочному буферу трансляции.
Для ускорения доступа к памяти MIPS R4000 (так же, как и процессоры
Intel) имеет массив ассоциативной памяти, так называемый справочный буфер
трансляции (translation lookaside buffer, TLB). Ассоциативная память, каковой
является TLB, — это вектор, ячейки которого могут одновременно считываться и
сравниваться с целевым значением. В случае TLB вектор содержит отображение
виртуальных адресов и физические для страниц, которые использовались самы-
ми последними, а также атрибуты защиты для каждой из них. Упрощенная схема
TLB показана на рис 6—9-
Для адресов, которые используются часто, высока вероятность присут-
ствия входов в TLB, что обеспечивает высокую скорость трансляции виртуаль-
ных адресов в физические и, следовательно, высокую скорость доступа к памяти.
Если виртуальный адрес отсутствует в TLB, он может по-прежнему находиться
в памяти, но на этот раз его должно найти программное обеспечение виртуаль-
ной памяти, а нс аппаратура, что несколько замедляет доступ. Когда виртуальная
страница откачивается па диск, диспетчер виртуальной памяти делает недей-
ствительным соответствующий входТЬВ. При обращении процесса к такой стра-
нице происходит страничная ошибка, диспетчер виртуальной памят и вновь пе-
реносит страницу в память и снова создает для нее вход TLB.
Для поиска ст раниц, отсутствующих в TLB, ядро н /диспетчер виртуальной
памяти используют таблицы страниц, создаваемые программно. Таблицы стра-
ниц используются большинством систем виртуальной памяти; в одних случаях
они реализованы аппаратно, в других — программно. Концептуально таблица
страниц напоминает структуру данных, приведенную на рис. 6-10.
Вход таблицы страниц (page table entry, РТЕ) содержит всю информацию,
необходимую системе виртуальной памяти для поиска страницы, когда поток
обращается по адресуй в пей. В простой системе виртуальной памяти недействи-
тельный вход означает, что страница отсутствует в физической памяти и се i iy-ж-
но загрузить с диска. Генерируется исключение страничной ошибки, программ-
ное обеспечение подкачки страниц загружает запрашиваемую страницу в па-
мять и обновляет таблицу страниц. Процессор повторно исполняет команду,
I
СНОВЫ WINDOWS NT
Таблица страниц
Виртуальным адрес
1
2
3
4
5
Страничный фрейм 3
Страничный фрейм 10
Недействительный
Недействительный
Страничный фрейм 7
Входы
- таблиц^
страниц
Страничный фрейм 5
Недействительный:
переходный
Недействительный
6
7
п
Рис. 6-10. Концептуальная схема таблицы страниц.
вызвавшую страничную ошибку. На этот раз, однако, вход таблицы страниц яв-
ляется действительным, и обращение к памяти выполняется успешно.
MIPS R4000 использует 32-разрядные адреса, т. е. для каждого процесса
доступно 212 виртуальных адресов. Процессор объединяет виртуальные адреса в
страницы длиной 212 байт (4 Кбайт), что дает 22", или 1.048.576 страниц в каждом
адресном прост ранстве. Если один вход таблицы страниц имеет размер 4 байт,
то для отображения всей виртуальной памяти требуется 1024 страничных фрей-
ма (220 умножить на 22 и разделить па 212). Причем это всего лишь для одного
адресного пространства! У каждого процесса имеется отдельное адресное про-
странство. Чтобы вся память не ушла лишь на хранение таблиц страниц, диспет-
чер виртуальной памяти по необходимости перемещает эти таблицы па диск и
обратно в память.
Процессор MIPS R4000 позволяет ОС использовать такой формат таблицы
страниц, который ей наиболее удобен. В противоположность этому, процессор
Intel 386 определяет его аппаратно. Чтобы обеспечить максимальную переноси-
мость между процессорами MIPS и Intel, диспет чер виртуальной памяти приме-
няет двухуровневую структуру таблицы страниц, напоминающую формат Intel.
Таблица первого уровня, называемая каталогом страниц (page directory), со-
держит указатели на страницы в таблице второго уровня. В последней находятся
указатели на фактические страничные фреймы, как показано на рис. 6 11-
При поиске входа таблицы страниц диспетчер виртуальной памяти (•'
ядро NT) транслирует виртуальный адрес формата MIPS в адрес формата Intel-
используя разные части адреса как смещения в структуре таблицы страниц. Кро-
ме того, один вход TLB всегда содержит виртуальный базовый адрес каталог-1
страниц исполняемого в данный момент процесса. (По этой причине оды’1
пользовательский процесс нс может “видеть” адресное пространство другого- -
них разные каталоги страниц, указывающие на разные таблицы страниц.)
Виртуальный адрес
Адрес каталога страниц
Рис. 6-11. Структура таблицы страниц на Intel 386 и MIPS R40006.
Входы каталога страниц и таблицы страниц процесса moi у г быть как дей-
ствительными, так и недействительными. Если вход каталога страниц недей-
ствителен, то генерируется страничная ошибка для загрузки страницы каталога
и поиска страницы таблицы страниц. После того, как последняя становится
действительной, проверяется соответствующий вход таблицы страниц. Если он
тоже недействителен, то генерируется новая страничная ошибка для поиска этой
страницы кода или данных.
Входы таблицы страниц NT являются расширением входов абстрактной
таблицы, показанной выше. Каждый вход таблицы (и каталога) страниц содер-
жит признак переходного состояния. Когда вход таблицы страниц отмечен как
недействительный и установлен признак переходного состояния, данная стра-
ница является кандидатом на повторное использование, но ее содержимое по-
прежнему действительно. Переходную страницу можно очень быстро снова
сделать действительной, так как диспетчеру виртуалы юй памяти не надо считы-
вать ее с диска. Входы таблицы страниц также содержат флаги, отмечающие тип
страничной защиты, назначенный каждой из страниц диспетчером виртуаль-
ной памяти.
Если страничный фрейм совместно используется двумя процессами, то
диспетчер виртуальной памяти вводит дополнительный уровень косвенности в
‘•Данная иллюстрация основана на рис. 5—9 из Intel R0.W6 Processor Reference Manual (Intel Corpora-
tion, 1988). 5-8-
Виртуальный адрес
Адрес каталога страниц
Рис. 6-12. Трансляция адреса совместно используемой памяти.
свои таблицы страниц, как показано на рис. 6-12. Дополнительная структура
данных, которую он вставляет, называется прототипным входом таблицы
страниц (prototype page table entry), или прототипным РТЕ.
Прототипный РТЕ. 32-разрядная структура, которая сходна с нормальным
входом таблицы страниц, позволяет диспетчеру виртуальной памяти управлять
совместно используемыми страницами, нс обновляя таблицы страниц всех
процессов, использующих страницу. Допустим, в определенный момент време-
ни страница совместно используемого кода пли данных была откачана на диск.
При считывании ее обратно в память диспетчеру виртуальной памяти необхо-
димо обновить только указатель, хранящийся в прототиппом РТЕ, чтобы он ука-
зывал на новое местоположение страницы. Вносить изменения в таблицы стра-
ниц всех процессов, совместно использующих данную страницу, не требуется.
Прототипныс РТЕ размещаются в нерезидентной системной памяти, поэтому
как п обычные входы таблицы страниц, они могут быть при необходимости
выгружены на диск.
Стратегия подкачки и рабочие наборы
Обычно системы виртуальной памяти определяют три типа стратегии, диктук’"
щей, как (или когда) выполняется подкачка: стратегия считывания, стратегия
размещения и стратегия замещения.
Стратегия считывания (letch policy) определяет, когда средство подкач-
ки должно перемещать страт тус диска в намя i ь. Огратегия считываг шя одг юго
1лава 6. Диспетчер виртуальной памяти
типа пыт ается загружать страницы, которые потребуются процессу, до того как
он их запросит. В соответствии с другой стратегией считывания, называемой
стратегией подкачки ио запросу (demand paging policies), страница загружает-
ся в память только тогда, когда происходит страничная ошибка. В системе с
подкачкой по запросу в начале исполнения процесса возникает много странич-
ных ошибок, так как его потоки обращаются к начальному набору страниц, не-
обходимому для запуска процесса. После того как эти страницы загружены в
память, интенсивност ь подкачки для данного процесса снижается.
Для загрузки страниц в память диспетчер виртуальной памяти NT исполь-
зует алгоритм подкачки по запросу с “кластеризацией’'. Когда поток генерирует
страничную ошибку, диспетчер виртуальной памяти загружает страницу, выз-
вавшую ошибку; вместе с небольшим количеством окружающих ее страниц. Та-
кая стратегия пытается минимизировать число страничных ошибок, возникаю-
щих при исполнении потока. Поскольку программы, особенно большие, имеют
тенденцию исполняться в данный момент времени в небольшом объеме своего
виртуального адресного прост ранства, то загрузка кластеров виртуальных стра-
ниц позволяет снизить число страничных ошибок.
При возникновении страничной ошибки система виртуальной памяти
должна также определить, в какое место физической памяти следует загрузить
виртуальную страницу. Набор используемых при этом правил называется стра-
тегией размещения (placement policy). Хотя для сегментных архитектур памяти
стратегия замещения часто бывает сложной, она обычно проста в линейных
архитектурах, где требуется лишь наши свободный страничный фрейм. В NT,
если память нс заполнена, диспетчер виртуальной памяти просто выбирает пер-
вый фрейм из списка свободных страничных фреймов. Если список пуст, дис-
петчер просматривает несколько других поддерживаемых им списков; порядок
просмотра зависит от типа обрабатываемой страничной ошибки (более под-
робно списки страничных фреймов рассматриваются в разд. 6.3.3).
Если страничная ошибка происходит, когда вся физическая память запол-
нена, то применяется стратегия замещения (replacement policy ), которая опре-
деляет, какую виртуальную страницу нужно извлечь из памяти, чтобы освобо-
дить место для новой страницы. К чилу часто используемых стратегий замеще-
ния относятся замещение используемого меньше всего (least recently used, LRU) и
“первым пришел, первым ушел" (first in, first out, FIFO). Алгоритм LRU требует,
чтобы система виртуальной памяти отслеживала, когда используется страница,
находящаяся в памяти. Если нужно загрузить новую страницу, то на диск выг-
ружается та страница, которая не использовалась дольше всех остальных, и ее
страничный фрейм освобождается для обработки страничной ошибки. Алгоритм
FIFO несколько проще: в соответст вии с ним на диск перемещает ся та страница,
которая дольше всех находилась в памяти, независимо от того, как часто она
использовалась.
Стратегии замещения можно далее классифицировать как глобальные или
локальные. Стратегия локального замещения (local replacement policy) выделя-
ет каждому процессу- фиксированное (или, как в NT, динамически настраивае-
мое) число стра! шчных фреймов. Когда процесс использует все выделенные ему
фреймы, программное обеспечение виртуальной памяти освобождает (т. е. уда-
ляет из физической памяти) одну из его страниц при каждой страничной ошиб-
ке в данном процессе. В случае стратегии глобального замещения для обработки
страничной ошибки используется любой страничный фрейм, независимо от-
того, принадлежит ли он процессу, в котором она произошла. Например, стра-
тегия глобального замещения по алгоритму FIFO должна отыскивать страницу
которая дольше остальных находилась в памяти, и освобождать ее для обраб<л
ки страничной ошибки; стратегия локального замещения ограничивает поиск
самой старой страницы набором только тех страниц, которые уже принадлежав
процессу, вызвавшему страничную ошибку.
Стратегия глобального замещения создает ряд проблем. Во-первых. нро.
цессы становятся подверженными влиянию поведения других процессов. На-
пример, если один или несколько процессов в системе используют большщ.
объемы памяти, весьма вероятно, что любое исполняющееся приложение будет
часто претерпевать страничные ошибки, и время его выполнения будет возрас-
тать. Во-вторых, плохое приложение может подорвать работу’ всей системы,
повышая интенсивность подкачки страниц во всех процессах. В Windows N]
важ! ю, чтобы подсистемам среды не приходилось бороться за память с другими
процессами. Для эффективной работы и адекватной поддержки своих клиент-
ских приложений подсистемы должны постоянно держать в памяти некоторое
количество страниц. По этим причинам диспетчер виртуальной памяти исполь-
зует стратегию локального замеще! шя FIFO. При таком подходе ему необходимо
отслеживать находящиеся в памята страницы для каждого процесса. Это множе-
ство страниц называется рабочим набором (working set) процесса7.
В момент создания процессу назначается минимальный размер рабочего
набора, т. е. минимальное число страниц процесса, которые гарантированно
будут присутствовать в памяти во время его исполнения. Если память не слиш-
ком загружена, то диспетчер виртуальной памяти позволяет процессу иметь в
памяти число страниц, равное максимальному размеру его рабочего набора4.
Если процессу потребуются допол! нательные c rpai шцы, диспетчер виртуальной
памяти удаляет одну из его страниц при каждой сгенерированной процессом
страничной ошибке.
Чтобы определить, какую страницу рабочего набора процесса удалить,
используется простой алгоритм FIFO, при котором из памяти удаляется та стра-
ница, которая была в ней дольше остальных. (Так как замещенные страницы
рабочего набора на самом деле еще на некоторое время остаются в памяти пос-
ле их замещения, их можно быстро вернуть в рабочий набор, и это не требует
считывания с диска. См. также разд. 6.3.3)
Когда физической памяти становится недостаточно, диспетчер виртуаль-
ной памяти использует метод, называемый автоматически м урезанием рабоче-
го набора (automatic working set trimming), для увеличения объема свободной
памяти. Он просматривает все процессы, сравнивая текущий размер рабочего
набора с минимальным. Когда диспетчер виртуальной памяти обнаруживает
процессы, использующие набор больше минимального, он удаляет страницы из
их рабочих наборов, так чтобы эти страницы можно было использовать в дру-
П. Дж. Деннинг fP. J. Denning), опубликовавший свою основополагающую работу по виртуальной на-
мята в 1970 году; обозначал термином рабочий набор (working .set) минимальное количество стран!111
процесса, которое должно находиться в памяти, прежде чем процесс сможет выполняться. Если чнс.Ю
страниц меньше рабочего набора, то процесс “пробуксовывает" (в нем постоянно встречаются стра-
ничные ошибки — thrashing). Наше оп|х.’дсление “набор страниц процесса, находящихся в памяти в
данный момент времени" несколько отличается от определения Деннинга, и их не следует путать.
" Диспетчер виртуальной памяти может также позволить процессу превзойти этот максимум, если
свободен очень большой объем памяти.
Глава 6. Диспетчер виртуальной памяти
тих целях. Если, несмотря па это, свободной памяти по-прежнему мало, диспет-
чер виртуальной памяти продолжает удалять страницы из рабочих наборов
процессов, пока рабочий набор каждого процесса не станет минимальным.
После того, как рабочий набор процесса уменьшился до минимума, дис-
петчер виртуальной памяти отслеживает число генерируемых данным процес-
сом страничных ошибок. Если процесс претерпевает страничные ошибки и
память не слишком загружена, то диспетчер виртуальной памяти увеличивает
размер рабочего набора. Однако, если в течение некоторого периода времени в
процессе не происходит страничных ошибок, то либо код, исполняемый пото-
ками процесса, комфортно умещается в минимальном рабочем наборе процес-
са. либо ни один из потоков процесса не исполняется. Например, процесс реги-
страции пользователя в системе просто ждет, пока пользователь не захочет за-
регистрироваться. После регистрации пользователя этот процесс ждет выхода
пользователя из системы. Для процесса регистрации пользователя и для других
процессов, которые большую часть времени простаивают, диспетчер виртуаль-
ной памяти продолжает снижать размер рабочего набора, пока в процессе нс
произойдет страничная ошибка. Страничная ошибка означает, что либо потоки
процесса вновь начали выполняться, либо достигнут минимальный размер па-
мяти. необходимый потокам процесса для выполнения.
Процесс может измените минимальный и максимальный размер своего
рабочего набора, вызвав сервис объект а-процесса, однако в базе данных ло-
кальной стратегии подсистемы защиты хранятся абсолютные минимальное и
максимальное значение для каждого процесса пользовательского режима. Не-
смотря па данную возможность, отдельным процессам по большей части нс тре-
буется изменять размеры своих рабочих наборов. Диспетчер памяти устроен
так, чтобы при помощи стратегии локального замещения и автоматического
урезания рабочего набора отслеживать нагрузку па память и соответствующим
образом корректировать се использование. Он пытается обеспечить максималь-
ную возможную производительность каждого процесса без настройки системы
пользователями или администратором.
6.3.3 База данных страничных фреймов
Таблицы страниц процесса содержат информацию о том, в каком месте физи-
ческой памяти расположены виртуальные страницы. Кроме того, диспетчеру
виртуальной памяти нужна структура данных для отслеживания состояния фи-
зической памяти. Например, ему' нужно знать, свободен ли данный страничный
фрейм, и если нет, то кто его использует. Для этой цели и служит база данных
страничных фреймов (page frame database). Она представляет собой массив
элементов, пронумерованных от нуля до числа страничных фреймов в системе
(минус 1). Каждый элемент содержит информацию о соответствующем стра-
ничном фрейме. База данных страничных фреймов и ее связь с таблицами стра-
ниц показаны на рис. 6—13. Как видно, действительные элементы таблицы стра-
ниц указывают на элементы базы данных страничных фреймов, а последние
указывают обратно на использующую их страничную таблицу. Диспетчер вирту-
альной памяти использует прямой указатель, когда процесс обращается по дей-
ствительному виртуальному адресу. Он следует по указателю, чтобы найти физи-
ческую страницу, соответствующую виртуальному адресу.
ЭВЫ WINDOWS NT
Некоторые недействительные элементы таблицы страниц также ссылакл
ся на элементы базы данных страничных фреймов. Эти “переходные” элементы
таблицы страниц указывают па страничные фреймы, которые могут быть. н<>
еще не использованы повторно, и, таким образом, их содержимое пока не изме-
нялось. Если процесс обращается к одной из таких страниц, преадс чем она
будет снова использована другим процессом, то диспетчер виртуальном памяти
может быстро восстановить ее.
Таблица страниц
процесса 1
База данных
страничных фреймов
Прямой указатель
Обратный указатель <-
Рис. 6-13. Таблицы страниц и базо донных страничных фреймов.
Глава 6. Диспетчер виртуальной памяти
Другие недействительные элементы таблицы страниц содержат,тисковые
ауцкса. по которым хранятся страницы. При обращении процесса к одной из
таких страниц происходит страничная ошибка, и диспетчер виртуальной памя-
ти считывает содержимое страницы с диска.
В любой момент времени страничный фрейм может находиться в одном
из шести состояний:
Действительный. Страничный фрейм используется процессом, и на
него указывает действительный элемент таблицы страниц.
Обнуленный. Страничный фрейм свободен и инициализирован пулями.
Свободный. Страничный фрейм свободен, но не инициализирован.
Резервный. Данный фрейм использовался процессом, побыл удален из
рабочего набора последнего. Соответствующий элемент таблицы стра-
ниц недействителен, но помечен как переходный.
Измененный. Данное состояние аналогично резервному, за исключени-
ем того, что процесс, использовавший этот фрейм, осуществил запись в
него, и содержимое еще не записано па диск. Соответствующий эле-
мент таблицы страниц недействителен, но помечен как переходный.
11лохой. Страничный фрейм вызвал ошибку четности или другой аппа-
ратный сбой, и его нельзя использовать.
База данных страничных фреймов группирует те неиспользуемые фрей-
мы, которые находятся в одном и том же состоянии, создавая таким образом
пять отдельных списков: список обнуленных, список свободных, список резерв-
ных, список измененных и список плохих страниц. Связь между базой данных
страничных фреймов и списками ст раниц показана па рис. 6-1 1.
Как видно, в данные списки включены все страничные фреймы компьюте-
ра, которые в данный момент' не используются. Указатели па используемые
фреймы содержатся в таблице страниц соответствующего процесса. Если про-
цесс освобождает страничный фрейм или если диспетчер виртуальной памяти
откачивает его содержимое на диск, то фрейм становится свободным, и диспет-
чер виртуальной памяти помещает его обратно в один из списков.
Если диспетчеру виртуальной памяти требуется инициализированный
страничный фрейм (тот, который содержит одни нули) для обработки странич-
ной ошибки, он пытается взять первый из списка обнуленных страниц: если
этот список пуст; то диспетчер выбирает фрейм из списка свободных н обнуляет
его". Если диспетчеру виртуальной памяти не нужна инициализированная стра-
ница, т о он берет первую из списка свободных; если список пуст, то использует-
ся первая из списка обнуленных. И в том и в другом случае, если оба списка
пусты, диспетчер виртуальной памяти использует список резервных. Всякий раз,
” Министерство обороны (ЛИЛ устанавливает, что. в соответствии с уровнем защиты С2. процессам
пользовательского режима должны передаваться только инициализированные страничные фреймы,
чтобы предотвратить доступ к содержимому памяти предыдущего процесса. Таким образом, диспет-
чер внрчуалыюи памяти передает процессу пользовательского режима обнуленные страничные
фреймы, если только процесс не загружает данные из дискового файла, например исполняемый об-
раз. В последнем случае диспетчер виртуальной памяти использует 1 ^обнуленные фреймы, инициа-
лизируя их данными с диска.
ЭВЫ WINDOWS NT
Рис. 6-14. Списки страниц в базе данных страничных фреймов.
когда количество страши i в списках обнуленных, свободных и резервных стра-
ниц снижается до порогового значения, поток, называемый средством записи
измененных страниц (modified page writer), “пробуждается”, записывает содер-
жимое измененных страниц на диск, после чего помещает их в список резерв-
ных для повторного использования.
Если даже список измененных стал слишком коротким, то диспетчер вир-
туальной памяти начинает урезать рабочие наборы всех процессов до их мини-
мальных размеров. Вновь освобожденные страницы помещаются в список из-
мененных или резервных для повторного использования по запросу. Диаграмм3
состояний страничного фрейма показана на рис. 6—15.
Прежде чем диспетчер виртуальной памяти сможет использовать страни-
цу из списка резервных или измененных, он должен обновить недействитель-
ный элемент таблицы страниц (или прототипный РТЕ), который по—прежнему
указывае т на данный фрейм. Возвращаясь к рис. 6—13, можно видеть, что элемен-
ты базы данных страничных фреймов содержат обратные указатели на таблиц}
страниц процесса, использовавшего их последним (или на прототипный РТЕ дл,]
совместно используемых страниц), что и позволяет выполнить обновление.
Глава 6. Диспетчер виртуальной памяти
Рис. 6-15. Диаграмма состояний страничных фреймов.
6.3.4 Дескрипторы виртуальных адресов
В одном из предыдущих разделов данной главы были описаны стратегии, при
помощи которых диспетчер виртуальной памяти определяет, когда загружать
страницу в память, где в памяти ее разместить и какие страницы следует удалять
при переполнении памяти.
Диспетчер виртуальной памяти использует алгоритм подкачки по запросу
для определения момента загрузки страницы в память. Прежде чем переписать
страницу с диска, он ждет, пока некоторый поток не обратится по расположен-
ному на ней адресу и не вызовет страничной ошибки. Подобная подкачка по
запросу является разновидностью отложенных вычислений. Алгоритмы отло-
женного вычисления избегают выполнения дорогостоящих операций, таких как
подкачка, пока это не станет абсолютно необходимым.
Диспетчер виртуальной памяти использует отложенные вычисления и в
другой области, а именно, для формирования таблиц страниц. Например, когда
поток выделяет большую область виртуальной памяти, можно было бы сразу же
создать таблицы страниц, i юобходимыс для доступа ко всему выделенному диа-
пазону адресов. Однако, если приложение использует не всю выделенную па-
ВЫ WINDOWS NT
мять, то создание таблиц страниц буде т напрасной тратой сил. Следователи к,
диспетчер виртуальной памяти нс делает этого до тех пор, пока не произойду,
страничная ошибка. Использование отложенных вычислений дает зиачитель.
ный выигрыш в производительности для приложений, резервирующих Mtioi()
памяти, по использующих (передающих) ее нс целиком.
Выделение памяти, даже больших блоков, с использованием алгоритма
отложенных вычислений выполняется очень быстро. Однако этот выигрыш в
производительности дается не даром. Когда поток выделяет намять, диспетчер
виртуальной памяти должен в ответ вернуть диапазон адресов, которые iioi()k
сможет использовать. Однако, поскольку таблица страниц процесса не загружа-
ется до тех пор, пока поток фактически не обра тится к памяти, диспетчер вир.
туальной памяти не может обратиться к пей, чтобы определить, какие виртуаль-
ные адреса свободны. Следовательно, диспетчер виртуальной памяти должен
поддерживать другой набор структ ур данных, чтобы отслеживать, какие адреса
из виртуального адресного пространства процесса уже заняты, а какие пет. В
этих целях и используются дескрипторы виртуальных адресов.
Для каждого процесса диспетчер виртуальной памяти поддерживае т набор
дескрипторов виртуальных адресов, описывающий состояние виртуального ад-
ресного пространства процесса (см. рис. 6—16).
Когда процесс выделяет память (или отображает проекцию совместно ис-
пользуемой памяти), диспетчер виртуальной памяти создает дескриптор вирту-
ального адреса для хранения всей информации, относящейся к запросу расп|тсде-
ления памяти: выделяемый диапазон адресов, будет ли эта область памяти совме-
стно используемой или собственной, может ли содержимое области памяти на-
следоваться дочерним процессом, а также каков тип защиты страниц. Затем этот
дескриптор виртуального адреса вставляется в древо дескрипторов виргуальных
адресов процесса (самобалансирумое двоичное древо) для ускорения его поиска
При первом обращении потока по некоторому адресу' диспетчер вирту-
альной памяти должен создать элемент таблицы страниц для страницы, содер-
жащей этот адрес. Для этого он ищет дескриптор виртуального адреса, в диапа-
зон адресов которого попадает данный адрес, и по информации из дескрипт ора
Рис. 6-16. Дескрипторы виртуольных адресов.
I лови о./ди titji е—ниртусгльнии о я
создает элемент таблицы страниц. Если адрес не попадает в диапазон ни одного
из дескрипторов, то диспетчер виртуальной памяти определяет, что поток пыта-
ется обратиться по адресу, который не был выделен; имеет место нарушение
доем ia к памяти.
.5 Соображения мультипроцессорной обработки
Любой код, который может выполняться одновременно па нескольких процес-
сорах, должен удовлетворять некоторым ограничениям. Он должен быть реен-
терабельным, предотвращать одновременное использование несколькими по-
токами глобальных структур данных и нс позволять двум потокам захватывать
ресурсы таким образом, чтобы заблокировать друт друга (взаимоблокировка,
или клинч, deadlock). Кроме того, на многопроцессорных системах существуют
специфические проблемы производительности (отсутствующие на однопро-
цессорных машинах).
Диспетчер виртуальной памяти peci тгерабелен, так что для него основны-
ми проблемами были предотвращение разрушения данных и взаимоблокиро-
вок, а также достижение хорошей производительности.
Для защиты своей самой важной структуры данных базы данных стра-
ничных фреймов — диспетчер виртуальной памяти использует спин—блокиров-
ку. Всякий раз, когда возникает страничная ошибка, средство подкачки страниц
перехватывает управление вызвавшим ее потоком, обрабатывает ошибку и об-
новляет базу данных. Прежде чем получить доступ к базе данных, поток должен
завладеть связанной с нею спин—блокировкой. Пока поток владеет спин—блоки-
ровкой, никакой другой поток не может читать или записыва ть в базу данных
страничных фреймов. Таким образом, когда в Windows NT происходят две стра-
ничных ошибки одновременно, один из потоков приостанавливается до осво-
бождения базы данных страничных фреймов.
Задержка доступа потока к базе данных страничных фреймов является
примером противоречия между скоростью выполнения и требованиями много-
процессорной системы. Диспетчер виртуальной памяти мог бы позволить не-
скольким потокам одновременно обращаться к разным частям базы данных,
разбив ее па несколько структур данных и защитив каждую часть отдельной
блокировкой. Однако получение н освобождение блокировки — дорогостоящая
операция, поэтому обработка страничных ошибок выполнялась бы дольше,
если бы потоку пришлось захватывать три блокировки вмест о одной. Ду Перац-
цолн, разработавший диспетчер виртуальной памяти, отдал предпочтение ско-
рости обработки страничных ошибок перед большей степенью параллелизма
средства подкачки страниц. Он решил использовать для защиты базы данных
одну блокировку; предполагая, что при меньших накладных расходах поток бу-
дет быстрее входить и выходить из владения базой данных, освобождая се для
других потоков.
Использование одной блокировки означает, что база данных страничных
фреймов може т стать узким местом при интенсивной подкачке страниц. Чтобы
избежать этого, диспетчер виртуальной памяти пытается минимизировать коли-
чество страничных ошибок. Для этого он делает следующее
предоставляет каждому процессу достаточное количестве} страниц в
рабочем наборе;
автоматически урезает рабочие наборы процессов, чтобы излишние или
неиспользуемые страницы стали доступны другим процессам.
Соображения переносимости
Диспетчер виртуальной памяти зависит от определенных аппаратных возмож-
ностей. Ниже приведены требования, которые он предъявляет к процессору;
32-разрядные адреса (64-разрядныс адреса поддерживаются, но тре-
буют некоторой переделки диспетчера виртуальной памяти).
Поддержка виртуальной памяти и подкачки страниц. Процессор дол-
жен предоставлять возможность отображения виртуальных адресов в
физические, а также предоставлять механизмы подкачки.
Прозрачные, когерентные аппаратные кэши на многопроцессорных
системах. Когда поток, исполняющийся на одном из процессоров, об-
новляет данные в кэше последнего, все другие процессоры должны полу-
чить уведомление, что их кэши теперь содержат некорректные данные.
Совмещение виртуальных адресов. Процессор должен допускать ото-
бражение на один и тот же страничный фрейм двух элементов таблицы
страниц одного и того же процесса. ОС часто использует страницу
совместно с пользовательским процессом, отображая второй элемент
таблицы страниц.
Некоторые части диспетчера виртуальной памяти зависят от особеннос-
тей процессора, на котором исполняется OG Перечисленные ниже части дис-
петчера памяти должны быть модифицированы для каждой аппаратной плат-
формы, на которую он переносится.
Элементы таблицы страниц. Когда элемент таблицы страниц действи-
телен, процессор подразделяет эти 32 бита на поля и устанавливает их
значения соответствующим образом. Когда элемент недействителен,
диспетчер виртуальной памяти использует остальной 31 бит по своему
усмотрению. Формат, выбираемый им, зависит от средс тв виртуальной
памяти, предоставляемых процессором.
® Размер страницы. Разные процессоры используют разные размеры
страницы. Диспетчер виртуальной памяти выделяет ее в пределах блока
в 64 Кбайт, что гарантирует возможность поддержки любого размера
страницы от 4 до 64 Кбайт. Страницы менее 4 Кбайт нс поддерживаются.
® Защита страниц. Способ использования диспетчером виртуальной па-
мяти аппара п той защиты ст раниц для реализации дополнительной про-
граммной защиты, естественно, аппаратно-зависим.
® Трансляция виртуального адреса. Алгоритм, используемый диенстчером
виртуальной памяти для трансляции виртуального адреса в номер эле-
мента таблицы страниц, тоже аппаратно—зависим.
Глава 6. Диспетчер виртуальной памяти
4 Заключение
Диспетчер виртуальной памяти Windows NT реализует изощренную систему
управления виртуальной памятью. Он предоставляет каждому процессу' боль-
шой набор виртуальных адресов, защищая эту память от других процессов, но
позволяя процессам эс])фективно совместно использовать память и предостав-
ляя им большие возможности управления. Имея надлежащие права доступа,
процесс также може г работать с адресным пространством других процессов
— это свойство используется подсистемами среды. Диспетчер виртуальной
памяти предоставляет и такие богатые возможности, как проецирование (рай-
лов и выделение несмежных участков памяти. Подсистема Win32 делает мно-
гие средства виртуальной памяти NT доступными приложениям через свой
32-разрядный API.
Диспетчер виртуальной памяти реализует постраничную защиту’ памяти,
дополняющую защиту страниц, которая предоставляется процессорами. Облас-
ти совместно используемой памяти реализованы как объекты, и, таким образом,
их использование управляется и контролируется средствами защиты, общими
для всех объектов. Кроме того, процесс может назначить постраничную защиту
отдельным областям совместно используемой памяти.
Где только можно, диспетчер виртуальной памяти использует технику
отложенных вычислений, чтобы не выполнять излишние, требующие больших
временных затрат операции до тех пор, пока это не станет абсолютно необхо-
димым. Это один из нескольких методов оптимизации, используемых диспетче-
ром для быстрого и эффективного доступа к виртуальной памяти.
В следующей главе мы сделаем еще один шаг вниз, к ядру NT — подлинно-
му цегпру Windows NT.
ГЛАВА 7
ЯДРО
.Иногда разработчики исполнительной системы NT говорят, что се ядро “дает
пищу всему остальному”. Эта метафора, хотя и неточная, верна по крайней
мерс в одном. Операционная система, как и любая большая программная сис-
тема, состоит из расположенных друг над другом уровней кода. Верхние уров-
ни используют более примитивные (но в данном случае более мощные) функ-
ции и структуры данных нижних уровней. Другая метафора, возможно, более
удачная, сравнивает ядро ОС со ступицей колеса. Это центр, вокруг которого
вращается все остальное.
Ядро выполняет наиболее фундаментальные функции Windows NT, опре-
деляя, как ОС использует процессор или процессоры и обеспечивая рациональ-
ность их использования. Таким образом, эффективность всей ОС зависит от
правильной и эффективной работы ядра.
Поэтому создание ядра NT должно было находиться в умелых руках. Его
спроектировал и реализовал Дэйв Катлер — руководитель группы разработки
Windows NT и основной архитектор системы. Дэйв, бывший главный консуль-
тант корпорации Digital Equipment Corporation (DEC), ранее участвовал в созда-
нии нескольких удачных ОС DEC, среди которых VAX/VMS и ОС RSX-11М для
машины PDP-11.
Главной задачей Дэйва при создании ядра NT было обеспечение базы, со-
стоящей из примитивов и механизмов с тщательно определенным и предсказу-
емым поведением, которые позволили бы высокоуровневым компонентам ис-
полнительной системы NT выполнять свои задачи. Используя примитивы ядра,
исполнительная система NT может создавать бесконечное разнообразие абст-
ракций высокого уровня. Ей нс нужно использовать для этого недокументиро-
ванные интерфейсы и хитрые трюки или непосредственно обращаться к аппа-
ратуре. Ядро отделяет себя от остальных частей исполнительной системе, реа-
лизуя механизмы ОС и избегая установления жестких правил. Почти все “поли-
тические” решения оно оставляет исполнительной системе NT'.
Предоставляя богатый набор контролируемых универсальных механизмов,
ядро NT позволяет Windows NT расти и расширяться предсказуемым и упорядо-
ченным образом. Ричард Рашид (Richard Rashid), объясняя причины, побудившие
с его коллегами создать ОС Mach (клиент-серверная версия UNIX), заметил, что
“ядро I'NIX стало “свалкой” практически всех новых средств и возможностей...
1 Ядро это komikmicih исполнительной системы, по имеющий особую природу. ДЛЯ простоты
в этой главе чермин Ш-Шмнштельная система (executive) используется для обозначения всех
компонентов работающих в режиме ядра, за исключением самого ядра.
Абстракции стали смешиваться, а информация стала беспорядочной”2. Это общая
участь, постигающая все популярные ОС после нескольких десятков лет суще-
ствования. Они натыкаются на свои архитектурные ограничения, расширяются и
после этого вновь натыкаются па ограничения. Ядро NT, полагаясь на простые,
расширясмые примитивы и избегая установления неизбежно устаревающих пру.
вил, пытается предохранить исполнительную систему' NT от такой участи.
Общие сведения
Отделение механизмов ОС от ее правил является важным принципом Window s-
NT. Механизмы — это способы выполнения различных задач в системе, и выра-
жением их являются алгоритмы и коя Правила или стратегии определяют, когда
и какие задачи должны быть выполнены, и даже следует ли вообще выполнять
некоторые из них. Код ОС, поддерживающий строгое разделение между меха-
низмами и стратегией, помогает системе оставаться гибкой. Со временем прави-
ла могут меняться, не вызывая множества изменений в системе или механизмах.
Принцип разделения механизмов и стратегий используется в Windows NT на
нескольких уровнях. На самом высоком уровне каждая подсистема среды устанав-
ливает слой правил ОС, отличающийся от устанавливаемого другими подсистема-
ми. Непосредственно под ними исполнительная система NT опредсляег другой,
более фундаментальный слой правил, подходящий для всех подсистем. На самом
нижнем уровне ОС ядро не устанавливает правил вообще. Вместо этого оно служит
прослойкой между остальными частями ОС и процессором. Ike операции, связан-
ные с процессором, обязательно проходят через ядро, что обеспечивает большую
переносимость и предсказуемость. Исполнительная система имеет лишь ограни-
ченное влияние на выполнение этих операций (посредством вызова функций ядра).
Помимо функций, предоставляемых исполнительной системой NT, ядро
решает четыре основных задачи:
планирует выполнение потоков;
• передает управление процедурам обработ ки при возникновении пре-
рываний или исключений;
® выполняет низкоуровневую многопроцессорную синхронизацию;
- реализует процедуры восстановления системы после сбоя питания.
Ядро отличается от других компонентов исполнительной системы не-
сколькими аспект ами. В отличие от других частей исполнительной системы-
оно никогда не откачивается из памяти. Аналогично, оно никогда не вытесня-
ется, хотя его работа может быть прервана для обработки прерывания (см. । т
8. “Система ввода-вывода”). Другими словами, на короткие периоды времени-
пока выполняется ядро, многозадачность исчезает. Ядро всегда работает в рС'
жиме ядра — привилегированном режиме процессора. Оно сделано небо.ть-
шим. компактным и настолько переносимым, насколько это позволяют сообра-
жения производительности и различия процессорных архитектур. Ядро напи-
сано в основном па С, с использованием ассемблера только для тех задач, ко-
- Richard Rashid, "Threads of a New Sr stem . / A/Л Keriew, August I486.
торые требуют максимально возможной скорости выполнения или сильно
зависят от особенностей процессора.
За пределами ядра исполнительная система представляет потоки и другие
совместно используемые ресурсы в виде объектов. Эти объекты требуют некото-
рых накладных расходов, связанных с правилами. Для работы с объектами необ-
ходимы описатели, проверки прав доступа, квоты ресурсов и рутинные механиз-
мы выделения и освобождения памяти. Ядро избегает этих накладных расходов,
поскольку реализует набор более простых объектов, называемых объектами ядра
(kernel objects). Они помогают ядру управлять цен тральным процессором и под-
держивают создание объектов исполнительной системы. Большинство объек-
тов уровня исполнительной системы включают в себя один или несколько
объектов ядра, объединяя их мощные атрибуты (определяемые ядром).
Одна группа объектов ядра, называемых управляющими объектами (cont-
rol objects), устанавливает семантику' управления различными функциями ОС. В
эту группу входят объект-процесс ядра, объект асинхронный вызов процедуры
(asynchronous procedure call, АРС), объект отложенный вызов процедуры (defer-
red procedure call, DPC) и несколько объектов, используемых системой ввода-
вывода. В их числе объект-прерывание, объект-уведомление питания и объект-
состояние питания. Другая группа объектов ядра, известных как диспетчерские
объекты (dispatcher objects), включает средства синхронизации и изменяет или
влияет на планирование потоков. К диспетчерским объектам относятся поток
ядра, мьютекс ядра, мутант ядра, событие ядра, пара событий ядра, семафор
ядра и таймер ядра. Исполнительная система использует функции ядра для
создания экземпляров его объектов, работы с ними и для создания более слож-
ных объектов, которые она предоставляет процессам пользовательского режи-
ма. Объекты ядра подробно обсуждают ся на протяжении этой и следующей глав.
Описание конструкции ядра связано с проблемой “курицы и яйца”. Не
ясно, с чего начать, так как каждая часть ядра использует друтис части. Поэтому
темы в данной главе рассматриваются в порядке общего интереса или значимо-
сти для функционирования ОС. Вначале обсуждается планирование потоков,
за этим — обработка прерываний и исключений. Далее обсуждается многопро-
цессорная синхронизация, за которой следует восстановление после сбоя пи-
тания (гема, тесно связанная с темой гл. 8 — системой ввода вывода).
7.2 Планирование потоков
Поток выполняется в адресном пространстве некоторого процесса и исполь-
зует ресурсы последнего. Одной из функций ядра NT является отслеживание
готовых к исполнению потоков и определение порядка, в котором они будут
выполняться, — задача, известная как планирование потоков (thread scheduling).
При выполнении необходимых условий ядро выбирает поток для исполнения
и переключает контекст на пего. Переключение контекста (context switch) —
это процедура сохранения текущего машинного состояния, связанного с ис-
полняющимся потоком, загрузка состояния другого потока и запуск последне-
го. Модулем, выполняющим эти обязанности, служит диспетчер’' ядра.
' Английский термин dispatch означает передать управление. В данном контексте имеется в виду не
редача управления потоку. < »н может также обозначат ь передачу управления соотвептвующей про
цедуре обработчику при возникновении прерывания или исключения.
i
Данный раздел начинается с базовой информации о представлении ц()
токов и процессов в ядре; пекле этого следует обсуждение обязанностей дцс
петчера, планирования и переключения контекста.
1 Объекты процесс ядра и поток ядра
Диспетчер должен следить за тем, чтобы из всех ожидающих исполнения ||()
токов процессоры всегда исполняли именно те, которые необходимо иснщ.
нять в данный момент. Когда в системе происходит событие, изменяющее- с<>.
стояние некоторого потока, диспетчер просматривает список ожидакнцщ
потоков и, если это необходимо, псреключаег контекст на новый поток.
Хотя диспетчер манипулирует потоками, он рассматривает их не так. как
это делают программы пользовательского режима или другие части ОС. Ядро
работает с сокращенной версией объекта—потока, называемой объект-попищ
ядра (kernel thread object). Объект-поток ядра содержится внутри объекта ц0.
тока исполнительной системы и содержит информацию, необходимую ядру дщ
направления потока на исполнение. Аналогично, ядро реализует минимальную
версию объекта-процесса, называемую объект-процесс ядра (kernel process
object). На рис. 7—1 показано соотношение между объектами процесс ядра и
поток ядра и их высокоуровневыми аналогами в исполнительной системе.
Как показано на рис. 7-2, объект-процесс ядра содержит указатель на спи-
сок потоков ядра. (Ядро ничего нс знает об описателях, так что оно действует в
обход таблицы объектов.) Кроме того, в объекте-процессе ядра находится ука-
затель на каталог таблиц страниц процесса (используется для отслеживания
объектов
Объекты-потоки
Рис. 7-1. Обьект-процесс ядро и объекты потоки ядро.
1ЛО о / ядро
виртуального адресного пространства процесса), общее время выполнения
всех потоков процесса, базовый диспетчерский приоритет процесса по умолча-
нию и набор по умолчанию процессоров, на которых могут исполняться потоки
процесса, — так называемое процессорное сродство (processor affinity). Управле-
ние информацией, хранящейся в объекте процесс ядра, осуществляет исключи-
тельно ядро. Другие части исполнительной системы могут считывать или изме-
нять се. только вызывая футжции ядра.
Объект-поток ядра более сложен, чем объект-процесс ядра. Он содержит
некоторую очевидную информацию, такую как процессорное сродство потока
(неполное подмножество сродства процесса) и общее время выполнения пото-
ка. Сюда также входят базовый приоритет потока (который может отличаться от
базового приоритета по умолчанию для процесса) и его текущий приоритет.
Особенно важный элемент данных, хранящихся в объекте—потоке ядра, — это
диспетчерское состояние потока. В любой момент времени поток может нахо-
диться в одном из шести состояний; из них только одно делает его кандидатом
на выполнение. Диспетчерские состояния потока показаны па рис. 7—3.
“Жизненный цикл” потока начинается тогда, когда программа создает- но-
вый поток. Этот запрос спускается вниз к исполнительной системе NT, где дис-
петчер процессов выделяет пространство для объекта—потока и вызывает ядро
для инициализации объекта—потока ядра, содержащегося внутри данного
объекта. После инициализации поток проходит через следующие состояния:
Готовый. Когда диспетчер ищет поток для выполнения, он рассматрива-
ет только пул потоков, находящихся в этом состоянии. Готовые потоки
просто ждут своего выполнения.
Резервный. Поток в резервном состоянии был выбран для выполнения
следующим на одном из процессоров. При выполнении определенных
условии диспетчер выполняет переключение контекста на этот поток.
Дня каждого процессора системы в резервном состоянии может быт ь
только один поток.
Исполняющийся. После того, как диспетчер переключает контекст ,
поток, последний переходит в это состояние и выполняется. Выполц?
ние потока продолжается до тех пор, пока он нс будет вытеснен ядрр'
для выполнения более высокоприоритетного потока, или не истсч/
сто квант времени, или он не завершится, или добровольно не перейд..
в состояние ожидания. 1
Ожидающий. Поток может перейти в состояние ожидания нссколькц^
способами. Он может добровольно ждать у объекта для синхронизащд
своего выполнения; ОС (например, система ввода-вывода) может ис4ат*
какого-либо события для него: или подсистема среды может приказам
потоку приостановиться. Когда ожидание потока заканчивается, он сцс
ва переводится в готовое состояние для продолжения выполнения.
Переходный. Поток находится в переходном состоянии, если он готов
к исполнению, но необходимые ему ресурсы недоступны. Например
стек ядра потока может быть откачан из памяти. Когда ресурсы стано-
вятся доступными, поток переходит в состояние готовности.
Завершившийся. Когда поток заканчивает свое исполнение, он перехо-
дит в завершившееся состояние. После своего завершения объект-по-
ток може т быть (а может и не быть) удален. (Стратегия удаления объек-
тов устанавливается диспетчером объектов.) Если у исполнительной
системы есть указатель на объект-поток, то она может повторно ини-
циализировать его и использовать снова.
Состояние ожидания требует несколько более подробного обсуждения.
Поток находится в состоянии ожидания, когда он ждет установки объекта или
группы объектов в состояние “свободен”. Как обсуждалось в гл. 4, “Процессы и
потоки”, объекты исполнительной системы, поддерживающие синхронизацию,
всегда находятся в одном из двух состояний: они либо свободны, либо заняты.
Объект остается в состоянии “занят” до тех пор, пока не произойдет какое-ни-
будь значительное событие. Поток, например, переводится в состояние “свобо-
ден”, когда завершается. Все пользовательские потоки, ждущие описателя завер-
шившегося потока, освобождаются и могут продолжить свое выполнение. Ана-
логично, файловый объект устанавливается в состояние “свободен”, когда завер-
шается операция ввода-вывода. Поток, ждущий у описателя файла, освобожда-
ется из состояния ожидания и может продолжать выполнение.
Факгичсски именно ядро реализует семантику' ожидания и сигнализации
Windows NT (нс путать с сигналами POSIX, которые более походят на исключения
NT). Каждый синхронизационный объект, видимый пользовательскому режиму,
включает в себя один или несколько диспетчерских объектов ядра. Например,
объект-поток содержит поток ядра, а объект—событие, как и объект—файл — со-
бытие ядра. Ядро отвечает’ за установку' диспетчерских объектов в состояние “сво-
боден” в соответствии с твердо определенными правилами; выполняя свою зада-
чу, ядро освобождает потоки, ждущие эти объекты, изменяя их состояние с “ожи-
дающий” на “готовый”. Это изменение, в свою очередь, говорит диспетчеру о не-
обходимости начать планирование потока (тема следующего раздела). Далее в
этой главе мы еще вернемся к диспетчерским объектам ядра и синхронизации.
Создать и инициализировать
объект-поток
Приоритеты планирования
Для определения порядка выполнения потоков диспетчер ядра использует’ си-
стему приоритетов, направляя на выполнение потоки с высоким приоритетом
раньше потоков с низкими приоритетами. Ядро даже прекращает исполнение,
или вытесняет (preempts) поток, если становится готовым к выполнению по-
ток с высшим приоритетом.
Первоначально приоритет потока устанавливается в соответствии с при-
оритетом процесса, в котором он был создан. Например, когда подсистема сре-
ды создает процесс, она назначает ему базовый приоритет по умолчанию (сис-
темное значение по умолчанию или число, заданное администратором). 11оток
наследует этот базовый приоритет и может изменять его так, чтобы он стал
немного больше или немного меньше. В результате получается приоритет пла-
нирования, с которым поток и начинает исполняться. В процессе исполнения
потока его приоритет может отклоняться от базового.
Для планирования выполнения потоков ядро поддерживает набор струк-
тур данных, известный как база данных диспетчера (dispatcher database). В базе
данных диспетчера отмечается, какие потоки ждут выполнения и какие потоки
на каких процессорах выполняются. Самая важная структура данных в базе дан-
ных диспетчера называется очередью готовности диспетчера (dispatcher ready
queue). На самом деле эго группа очередей — по одной для каждого приоритета.
Очереди, показанные на рис. 7—4, содержат готовые потоки, ждущие направле-
ния на исполнение.
Как видно из рисунка, исполнительная система NT поддерживает 32 уров-
ня приоритетов; потоки делятся на два класса: реального времени и переменно-
НОВЫ WINDOWS NT
Приоритет
планирования
Процессор 0 Процессор 1 Процессор 2
Потоки простоя
7.2,
Рис. 7-4. Очередь готовности диспетчера.
го приоритета. Потоки реального времени, имеющие приоритеты от 16 до 3'-
— это высокоприоритетные потоки, используемые программами с критически-'1
временем выполнения (например, приложениями управления и автоматизм
ции), которые требуют немедленного внимания процессора.
Для выбора очередного кандидата на исполнение диспетчер начипяе*1
очереди наивысшего приоритета и спускается вниз до тех пор. пока не паиХ*
поток; следовательно, все потоки реального времени будут выполняться прсЯ'-1
потоков переменного приоритета. Большинство потоков в системе относя'гся^
классу переменного приоритета, с уровнями приоритета от- I до 15 (приор*111’
О зарезервирован для системных целей). Эти потоки называются потоками 1,1
ременного приоритета (variable priority), так как диспетчер корректируй* ,г
приори теты во время работ ы для оптимизации времени отклика системы ,,‘1
пример, так как Windows N'l является системой с вытесняющей многозадз1***1
стью, диспетчер прерывает поток, после того как последний израсход*,|,‘1
свои квант времени. Если прерванный поток — это поток переменного
приоритета, то диспетчер понижает его приоритет. Таким образом, приори-
тет потока, выполняющего много вычислений, постепенно понижается (до
его базового приоритета).
С другой стороны, диспе тчер повышает приоритет потока после освобож-
дения последнего из состояния ожидания. Обычно добавка к приоритет}' потока
определяется кодом исполнительной системы, находящимся вне ядра, однако
величина этой добавки определяется тем, какого события ожидал поток Напри-
мер, поток, ожидавший ввода с клавиатуры, получает большую добавку', чем по-
ток, ожидавший завершения дискового ввода—вывода. В общем и целом, имеется
тенденция к установлению для интерактивных потоков высокого переменного
приоритета, для потоков, выполняющих ввод-вывод — среднего и для вычисли-
тельных потоков — низкого. (Приоритет потока переменного приоритета не
может быть повышен до уровня потоков реального времени.)
Процессорное сродство потока также влияет на порядок исполнения по-
токов. Ядро выбирает поток в зависимости от его приорите та и затем проверяет,
на каких процессорах он может исполняться. Если процессорное сродство по-
тока нс позволяет ему выполняться ни на одном из свободных процессоров, то
будет выполняться следующий по приоритету поток
Когда в системе ничего не происходит, ядро предоставляет для каждого про-
цессора один поток, который всегда готов выполняться. Такие потоки называются
потоками простоя; диспетчер считает, чао их приоритет ниже приоритета всех
остальных потоков. Поток простоя всего лишь (в цикле) проверяет, нс появился ли
в резервном состоянии другой поток, готовый к исполнению на данном процессо-
ре. При обнаружении такого потока поток простоя инициирует переключение
контекста на него. Потоки простоя проверяют также наличие ожидающих выпол-
нения отложенных вызовов процедуры (DPC). DPC описаны в разд. 7.3.2.3-
.3 Переключение контекста
После того, как истек квант времени потока, ядро вытесняет его и выполняет
перепланировку загрузки процессора. Однако истечение кванта времени —нс
единственная причина начала планировки. Она начинается, когда исполнение
текущего потока нс может продолжаться или когда изменилось состояние не-
которого потока и текущий поток не является более самым высокоприоритет-
ным. Некоторые условия, вызывающие перепланировку, перечислены ниже
* Поток становится готовым к выполнению — например, вновь инициализи-
рованный поток или поток только что вышедший из состояния ожидания.
* Истек квант времени потока, поток завершился или вошел в состояние
ожидания.
1 Диспетчер пли исполнительная система (возможно, по запросу при-
кладной программы) изменили приоритет потока.
Исполни тельная система или прикладная программа изменили процес-
сорное сродство выполняющегося потока.
Цель перепланировки — выбор потока, который будет выполняться сле-
дующим па некотором процессоре, и перевод его в резервное состояние. Од-
WINDOWS NT
нако просто найти поток недос таточно. Диспетчер также должен папраВ|(1
его на выполнение.
Когда выполняющийся поток завершился или нс может продолжать Jt.
полнение по другой причине, диспетчер прос то выполняет переключение КС|
текста на новый поток. В других случаях от диспетчера требуется болыц.
Пусть, например, высокоприоритетный поток реального времени сгановщ.
готовым к выполнению, но выполняется поток с меньшим приоритетом. В з1Г)|
ситуации диспетчер должен вытеснить исполняющийся поток. Для этого г»
запрашивает программное прерывание, чтобы начать переключение коптекс|.
как показано на рис. 7—5.
Выполняя перепланировку' потоков, ядро использует базу данных диспетчер
чтобы быстро определить, какие процессоры заняты, какие простаивают (испоЛ11а
ют поток простоя) и каковы приоритеты потоков, исполняющихся на каждом ц,
процессоров. В данном примере ядро (выполняющееся па процессоре А) опред.
ляет, что процессор В выполняет поток с меныпим приоритетом, чем у вновь пу|(л
вого потока. Ядро запрашивает диспетчерское прерывание для вытеснения потока
исполняющегося на процессоре В. Ядро, выполняющееся на процессоре В, обраба-
тывает прерывание путем перепланирования, т. е. переключает контекст с поток,
приора пета 3, выполняющегося на этом процессоре, на новый поток. Вытеа юнньй
Время
Процессор
А
(Приоритет 5)
Процессор
В
(Приоритет 3)
Исполняющийся поток устанавливает
событие, в результате чего ожидающий
поток становится готовым с приоритетом 4.
Перепланировать
Может ли вновь готовый поток выполняться
на другом процессоре?
Да. Перевести поток в резервное
состояние для процессора В
и запросить диспетчерское
прерывание для этого процессора----—г-
-------> ПРЕРЫВАНИЕ
Возобновить исполнение
Вытеснить исполняющийся поток
и перевести его в готовое состояв^
(Приорите г 5) Выполнить переключение контекс’
на резервный поток
(Приоритет 4)
Рис 7-5. Планирование потоков в многопроцессорной системе.
[лава 7. Ядро
поток возвращается в готовое состояние и снова помещается в очередь готовности
диспетчера для направления на исполнение в будущем, возможно, на другой про-
цессор. Хотя большинство потоков помещаются в конец очереди своего приори-
тета, вытесненный поток пользуется привилегией помещения в ее начало.
Контекст потока и процедура переключения контекста зависят от архи-
тектуры процессора. Обычно переключение контекста требует сохранения и
новой загрузки следующих данных:
в Счетчик команд
Регистр состояния процессора
Содержимое друтих регистров
Указатели стеков пользователя и ядра
м Указатель на адресное пространство, в котором выполняется поток (ка-
талог таблиц страниц процесса).
Для переключения контекста ядро сохраняет эту информацию, помещая
ее в стек режима ядра текущего потока и обновляя указатель стека. Ядро загру-
жает контекст нового потока и, если это поток другого процесса, загружает
адрес каталога таблиц страниц процесса, чтобы сделать доступным его адрес-
ное пространство. После выполнения ядром некоторой очистки управление
передается по адресу, указываемому загруженным счетчиком команд, и поток
начинает выполняться.
Здесь стоит вновь повторить, что, хотя поток, выполняющий код исполни-
тельной системы NT, может вытесняться более высокоприоритетным потоком,
поток, выполняющий код ядра, не вытесняется. Фактически во время своей рабо-
ты ядро выполняется с наивысшим приоритетом (на самом деле, оно временно
отключает планирование потоков). Хотя ядро не может вытесняться, его работу,
как правило, могут прерывать прерывания высокого уровня (тема, рассматрива-
емая далее в этой главе).
Обработка прерываний и исключений
Прерывания и исключения — это состояния в ОС, переключающие процессор на
код, лежащий вне нормального потока команд. Они могут обнаруживаться как
аппаратно, так и программно. При обнаружении прерывания пли исключения
процессор прекращает выполнять то, что он делал в данный момент, п передает
управление в особое место памяти по адресу кода, обрабатывающего возник-
шее состояние. В NT этот код называется обработчикам ловушки (trap handler).
Ядро NT различает прерывания и исключения. Прерывание (interrupt) —
это асинхронное событие, которое может произойти в любой момент времени,
независимо оттого, чем занят процессор. В основном прерывания генерируют-
ся устройствами ввода—вывода и таймерами процессора и могут быть разре-
шены (включены) или запрещены (отключены).
В противоположность этому, исключение (exception) - это синхронное
состояние, возникшее в результате выполнения некоторой инструкции. 11склю-
чения мслут быть воспроизведены посредством повторного выполнения тон же
программы, с темп же данными и в тех же условиях. Примеры исключений
нарушение защиты памяти, некоторые отладочные команды и ошибки деления
СНОБЫ WINDOWS NT
i/ujtnj /. >iz4->o
на ноль. Ядро NT также рассматривает- как исключения вызовы системных с
висов (хотя технически это системные ловушки).
Далее обсуждается реализация обработки прерываний и исключение
процессоре MIPS R4000. Реализации, используемые Windows NT при других а *
хитектурах. могут отличаться из-за различий в поддержке, обеспечиваемой
ными процессорами.
.3.1 Обработчик ловушки
Термином.ювушка (trap) обозначается механизм, используемый процессор^ ?*
(при возникновении в исполняющем потоке прерывания или исключения)
перехвата управления, переключения из пользовательского режима в режим и
и передачи управления в фиксированную точку ОС. В Windows NT процессор П[.. гй
редает управление обработчику ловушки ядра NT. Этот модуль играет роль коацц. •>'
тационной панели; он принимает исключения и прерывания, генерируемые про.
цессором, и передает управление коду обработки соответствующей ситуации.
Исключения и прерывания могут генерироваться как аппаратно, так и про.
граммно. Например, исключение ‘"ошибка шипы” вызывается аппаратной про
блемой, в то время как исключение ‘‘деление на ноль” возникает- из-за ошибц
в программе. Аналогично, прерывание может генерироваться устройство»
ввода—вывода, но и само ядро может- вызвать программное прерывание. На
рис. 7-6 показаны некоторые условия, приводящие к активизации обработчик
ловушки, и модули, которые он вызывает для обработки этих условий.
В момент своего вызова обработчик ловушки кратковременно запрещай
прерывания и сохраняет состояние машины (информацию, которая бы пропала
если бы возникло новое прерывание или исключение). Он создаст кадрловуша
Рис. 7-6. Распределение прерываний и исключений.
{A"
(trap frame), в который помещает информацию о состоянии исполнения пре-
рванного потока. Эта информация позволш ядру возобновить исполнение по-
тока после обработки прерывания или исключения. Обычно кадр ловушки явля-
ется подмножеством полного контекста потока. Как уже говорилось в предыду-
щем разделе, контекст потока зависит от архитектуры процессора.
Некоторые проблемы, вроде отдельных исключений виртуальной адреса-
ции, обработчик ловушки решает самостоятельно, по в большинстве случаев он
определяет тип возникшего состояния и передает управление другому модулю
ядра или исполнительной системе. Например, если произошло прерывание от
устройства, то управление передается процедуре обработки прерывания (inter-
rupt service routine, ISR), предоставляемой драйвером данного устройства. Если
прерывание возникло в результате вызова системного сервиса, то обработчик
ловушки передает управление коду системного сервиса в исполнительной систе-
ме NT. Остальные исключения обрабатываются собственным диспетчером ис-
ключений ядра. Следующие далее разделы более подробно рассматриваю!- рас-
пределение прерываний и системных сервисов, а также обработку исключений.
7^2 Распределение прерываний
Л? Прерывания, сгенерированные аппаратно, обычно исходят от устройств ввода-
вывода, которые должны уведомлять процессор о необходимости их обслужи-
вания. Устройства, способные генерировать прерывания, позволяют ОС обеспе-
чить максимальную загрузку процессора путем совмещения во времени вычис-
лений и операций ввода—вывода. Процессор запускает- операцию ввода—вывода
на устройстве и выполняет другие потоки, пока осуществляется пересылка дан-
, ных. Когда устройство закончило обмен, оно генерирует прерывание для вы-
полнения обслуживания. Координатные устройства, принтеры, клавиатуры, дис-
ки и сетевые карл ы обычно генерируют прерывания.
Системное программное обеспечение также может генерировать преры-
вания. Например, ядро может возбудоть программное прерывание для запуска
планирования потоков и для асинхронного вмешательства в процесс исполне-
ния потока. Ядро может отключить прерывания, чтобы процессор не “видел” их,
но делает эго редко — например, в критические моменты обслуживания преры-
ваний или исключений.
На прерывания реагирует подмодуль обработчика ловушки ядра, диспет-
чер прерываний. Он определяет источник прерывания и передает управление
либо внешней процедуре обслуживания, называемой процедурой обработки
прерываний (ISR), либо внутренней процедуре ядра. Драйверы устройств предо-
ставляют ISR для обслуживания прерываний от устройств, а ядро содержи т про-
цедуры обслуживания других типов прерываний.
Следующий подраздел начинается с описания типов прерываний, поддер-
живаемых ядром NT. Далее подробно описывается обработка прерываний и
кратко обсуждается способ взаимодействия драйверов устройств с ядром. Пос-
ледний подраздел описывает распознаваемые ядром программные прерывания
и используемые при их обслуживании объекты ядра.
^•2-1 Типы и приоритеты прерываний
Разные процессоры могут распознавать разнос количество и разные типы
прерываний. Диспетчер прерываний отображает аппаратные уровни преры-
ЗСНО Ы WINDOWS NT
1ловс /. Удро
ваний в стандартный набор уровней прерываний (interrupt request level, !pr..
распознаваемых ОС.
Уровни IRQL ранжируют прерывания по приоритетности. Их не следует
шивать с описанными выше приоритетами планирования. Приоритет планцр(
ния — это атрибут потока, в то время как IRQL — атрибут источника прерыва}
такого как мышь или клавиатура. Кроме того, каждый процессор имеет- теку,*1 * **'
IRQL, который изменяется в процессе работы ОС. Поток, работающий в pei^
ядра, может повышать или понижать текущий IRQL процессора, на котором вцГ]
няется, чтобы замаскировать или демаскировать прерывания нижних уровней.
Ядро определяет набор переносимых IRQL, который может модпфИ|^
роваться, если у данного процессора есть особые возможности, связанные
прерываниями (например, второй таймер). Прерывания обслуживаются в DJ
рядке приоритета. Прерывание с большим приоритетом вытесняет обрабо^
прерывания с меньшим приоритетом. Переносимые IRQL приведены в табл ij
в порядке убывания приоритета.
Таблица 7-1. Уровни прерываний (IRQL)
яй
•Г'
ft
-51М
$
Ife
Н:
Процессор А
IRQL = Таймер
Прерывания,
замаскированные -
на процессоре А
Текущий IRQL
Высший
Питание ____________
Межпроцессорное уведомление
Таймер ______________
Устройство п
Устройство 1
Диспетчерский/DPC
АРС
Низший
Процессор В
:— IRQL = Диспетчерский/DPC
Прерывания, замаскированные
на процессоре В
IRQL Тип прерывания
Высший уровень Аппаратная проверка или ошибка шины4
Уровень питания Сбой питания
Уровень межпроцес- Рабочий запрос от другого процессора
сорных прерываний
Уровень таймера Интервальный таймер
Уровень устройства п Устройство ввода—вывода высшего приоритета
Уровень устройства 1 Уст ройство ввода—вывода низшего приоритета
Уровень диспетчер- Планирование потоков и обработка отложенного
ский/DPC вызова процедуры (DPC)
Уровень АРС Обработка асинхронного вызова
процедуры (АРС)
Низший уровень Обычное исполнение потока
!ЧД"
«*?
IS
Уровни IRQL с самого старшего по первый IRQL устройства зарезервяр0
ваны для аппаратных прерываний; прерывания уровней диспетчерский/DPC®
АРС — это программные прерывания, генерируемые ядром. Низший IRQL
самом деле не является уровнем прерываний — он относится к нормальной
выполнению потока, при котором все прерывания разрешены.
Текущий IRQL катедого процессора определяет, какие прерывания мОЯ^
получать данный процессор. В процессе выполнения поток режима ядра повь'
шает или понижает процессорный IRQL. Как показано на рис. 7—7, источник
прерываний, уровень которых выше текущего, могут прерывать работу npo4£t
сора, в то время как прерывания от источников с IRQL, равным или меньн111'
чем текущий, блокируются, или маскируются (masked), до тех пор, пока |Я,!
полняющийся поток не понизит IRQL.
1 Такого рода катастрофические аппаратные ошибки обычно- генерируют исключения, а не нрср1’’
ванн». Однако при их возникновении ядро поднимает IRQL процессора до высшего уровня, мае'10' jk
руя все прерывания, что позволяет ему немедленно выполнить останов машины и предотвратит1’
возможный ущерб. к, JBj
Рис. 7-7. Маскирование прерываний.
Поток режима ядра повышает IRQL процессора, на котором он исполня-
ется, в зависимости от того, что он в данный момент пытается сделать. Напри-
мер, когда происходит прерывание, обработчик ловушки (или, возможно, про-
цессор) понижает IRQL процессора до уровня, назначенного источнику пре-
рывания. Это блокирует все прерывания данного и низших уровней (только на
этом процессоре) и гарантирует', что обслуживающий прерывание процессор
не будет перехвачен менее важным прерыванием. Замаскированные преры-
вания либо обслуживаются другим процессором, либо задерживаются, пока
IRQL не снизится. Изменение IRQL процессора — это мощная операция, кото-
рую следует выполнять с большой осторожностью. Потоки пользовательского
режима не могут изменять IRQL процессора.
Каждый уровень прерываний имеет особое назначение. Процессор гене-
рирует прерывание питания, когда он обнаруживает падение напряжения в ис-
точнике питания. При возникновении этого прерывания ОС выполняет автома-
тический останов, предварительно записывая критическую информацию о те-
кущем состоянии системы, чтобы после восстановления питания она могла про-
должить работу с того же места (подробнее см. разд. 7.5). Ядро генерирует меж-
процессорное прерывание (IPI), чтобы запросить у другого процессора выпол-
нение некоторого действия, например, чтобы направить некоторый поток на
исполнение или обновить кэш справочного буфера трансляции (TLB). Систем-
ный таймер генерирует прерывания через определенные интервалы времени, и
ядро обрабатывает их, обновляя текущее значение часов и замеряя время вы-
полнения потока. Если процессор поддерживает два таймера, то ядро добавля-
ет еще один уровень таймерных прерываний для измерения производительно-
сти. Ядро предоставляет ряд уровней генерирующим прерывания устройствам:
точное число этих уровней зависит от процессора и конфигурации системы.
Программные прерывания уровней IRQL диспетчерский/DPC и АРС использу-
ются ядром для инициирования планирования потоков и асинхронного вме-
шательства в процесс исполнения потока. Программные прерывания описа-
ны в разд. 7-3.2.3-
Глава 7. Ядро
ЗНОВЫ WINDOWS NT
.2.2 Обработка прерываний
При возникновении прерывания обработчик ловушки сохраняет состоя,
машины и вызывает диспетчер прерывании. Последний немедленно повьгц,^
IRQL процессора до уровня источника прерывания, чтобы замаскирова ть Г1^
рывания этого и низших уровней на время обработки.
Как и многие другие ОС, NT использует для поиска обработчика Дагцц^
прерывания таблицу распределения прерываний (interrupt dispatch table, Цц.
Индексом таблицы служит IRQL источника прерывания, а входы таблицы у каз^.
вают на процедуры обработки прерываний (рис. 7-8).
После выполнения процедуры обработки прерывания диспетчер ирерЬ1.
ваний понижает IRQL процессора до отметки, на которой он находился пср^
возникновением прерывания, после чего снова загружает сохраненное состоя,
нис машины. Прерванный поток возобновляет исполнение с точки, в которэд
произошло прерывание. При снижении ядром IRQL могут вскрыться замаскщх.
ванные прерывания нижних уровней. В этом случае ядро повторяет описанный
выше процесс для обработки нового прерывания.
У каждого процессора имеется отдельная таблица распределения преры-
ваний. так чтобы разные процессоры могли при необходимости выполнять раз-
ные ISR. Например, в многопроцессорной системе каждый процессор получай
прерывание таймера, но только один из них обновляет при его получении сис-
темные часы. Однако все процессоры использутот это прерывание для отечен
кванта времени и, по его истечении, для начала перепланировки для текущего
S
Таблица распределения
Высший
Питание
прерываний (IDT)
7) Происходит
прерывание
IDT
Таймер
Устройство п
*- Системная процедура останова
Системная процедура обработки
сбоя питания
Обработчик межпроцессорных
прерываний
Обработчик таймера
ISR устройства п
&
Я
Пе.
•Ж''
rf£.
лг
«Иг
4W-
Ли
•йь
»•
п/
iv
:Tf
"А
7) Диспетчер прерываний
получает IRQL источника
прерывания и использует
его как индекс в IDT
Устройство 1
Диспетчер прерываний
следует по указателю и
вызывает соответствующую
процедуру обработки
потока. Некоторые конфигурации системы могут требовать, чтобы прерыва-
ния от того или иного устройства обслуживались конкретным процессором.
Большинство процедур обработки прерываний находится в ядре. Ядро,
например, обновляет системное время и выполняет останов системы по сбою
питания. Однако многие прерывания генерируются внешними устройствами, та-
кими как клавиатура, координатные устройства и диски. Следовательно, драйве-
рам необходим способ сообщить ядру, какую прог (сдуру следует вызвать прг г воз-
никновении прерываний от соответствующих устройств.
Ядро предоставляет переносимый механизм — управляющий объект ядра,
так назваемый объект—прерывание (interrupt object), — который позволяет
драйверам регистрировать ISR для своих устройств. Объект-прерывание со-
держит всю информацию, необходимую ядру для того, чтобы связать 1SR уст-
ройства с некоторым уровнем прерываний; опа включает адрес ISR, IRQL уст-
ройства и вход IDT — ядра, с которым должна быть связана ISR. Связывание
процедуры обработки прерываний с некоторым уровнем прерывании назы-
вается подключением объекта—прерывания (connecting an interrupt object), а
отсоединение от входа IDT — отключением объекта—прерывания (disconnec-
ting an interrupt object). Эти операции, выполняемые с помощью вызова функ-
ции ядра, позволяют драйверу' устройства “включать” ISR при его загрузке в
систему и снова “отключать” се, если он выгружается.
Использование обьекта—прерывания для регистрации ISR позволяет драй-
верам не работать непосредственно с аппаратурой прерываний, которая раз-
личается для разных архитектур процессоров, и избавляет от необходимости
знать подробности таблицы распределения прерываний. Это средство ядра по-
могает создавать переносимые драйверы устройств, так как устраняет необхо-
димость программирования на ассемблере или отражения в драйвере устрой-
ства различий между процессорами.
Объекты-прерывания дают и другие преимущества. При помощи объек-
та-прерывания ядро може т синхронизировать исполнение ISR с другими частя-
ми драйвера, возможно - используя общие данные (подробнее см. гл. 8, “Систе-
ма ввода—вывода”). Болес того, объекты -прерывания позволяют ядру легко вы-
зывать более одной ISR для данного уровня прерываний. Если несколько драйве-
ров устройств подсоединяют созданные ими объекты-прерывания к одному и
тому же входу’ IDT, то при возникновении прерывания на данном уровне диспет-
чер прерываний вызывает каждую из процедур. Это позволяет ядру легко под-
держивать “цепочечные” конфигурации, в которых несколько устройств гене-
рируют прерывания на одном уровне.
Диспетчерский/DPC
АРС
Низший
ISR устройства 1
Обработчик потоков/обработчик
Обработчик АРС
(нет)
Рис. 7-8. Обслуживание прерывания.
^3-2.3 Программные прерывания
Хотя большинство прерываний генерируется аппаратурой, ядро NT также ге-
нерирует программные прерывания в своих целях. Это:
инигцгированис планирования потоков;
* обработка истечения интервала таймера;
к* асинхронное выполнение процедуры в контексте заданного потока;
в поддержка асинхронного ввода—вывода.
Ниже следуют описания соответствующих задач.
Диспетчерские пр-рыпания. Вам уже известно одно из мест, гдс
использует программные прерывания — в диспетчере потоков. Когда псуц^л
может более выполняться (возможно, из-за того, что он завершился или
описателя объекта), ядро напрямую вызывает диспетчер, чтобы немедлецц f
рсключить контекст. Однако иногда ядро обнаруживает необходимость
планировки, когда оно находится глубоко под несколькими слоями кода. р
ситуации идеальным решением оудст запросить планирование, но отложиц,
выполнение до того момента, когда ядро завершит текущие действия. Удобц
способ реализации — использование программного прерывания.
Для целей синхронизации (см. разд. 7.4) ядро на время своей работы i-<tl
повышает IRQL процессора до уровня диспетчерский/DPC или выше, что
кирует программные прерывания (и отключает планирование потоков). pfJ|
ядро определяет, что требуется перепланирование потоков, оно запрашивав
прерывание уровня диспетчерский/DPC, ио, поскольку текущий IRQL находцТс'
на этом же уровне или выше, то процессор только запоминает данное прерын,
ние. Завершив свою текущую работу, ядро понижает IRQL ниже уровня диепц
черский/DPC, и диспетчерское прерывание демаскируется.
Прерывания отложенного вызова процедуры (DPQ. Активизациядас-
петчера с использованием программного прерывания — это способ отложить пе-
реключение потоков до наступления подходящих условий. NT также использда
программные прерывания, чтобы отлжить выполнение других типов обрабсяж
Переключение потоков проходит на IRQL диспетчерский/DPC. Прерыва-
ния этого уровня поступают через обработчик ловушки к диспетчеру, который
выполняет планирование потоков. “По дороге” ядро обрабатывает также отло-
женные вызовы процедур (DPC). DPC — это функция, выполняющая системную
задачу; менее важную, чем та, которая выполняется в данный момент. Такие фун-
кции называются “отложенными”, так как они могут нс выполняться сразу. Ана-
логично диспетчерским прерываниям, DPC выполняются только после того, как
ядро (или часто система ввода—вывода) закончит выполнение более важк юй зада-
чи и опустит IRQL процессора ниже отметки диспетчерский/DPC.
DPC дают ОС возможность генерировать прерывание и исполнять систем-
ную функцию в режиме ядра. Ядро использует DPC для обработки истсчсни*
интервала таймера (и освобождения потоков, ждущих таймеров) и для перепла-
нировки процессора после истечения кванта времени потока. Драйверы уст-
ройств используют DPC для завершения обработки запросов ввода выво$
(подробнее см. гл. 8, “Система ввода—вывода”).
Представлением DPC является ибъект-DPC (DPC object) — управляют1®
объек т ядра, который невидим программам пользовательского режима, но В11
дим драйверам устройств и другому системному’ коду. Самая важная часть 11,1
формации, хранящейся в объекте— DPC, — адрес системной функции, котор®1
будет вызываться ядром при обработке данного прерывания DPC. ОжндаклЛ^
своего выполнения процедуры DPC хранятся в управляемой ядром очерС®*'
называемой очередью DPC. Чтобы запросить DPC, системный код обращается
ядру для инициализации объекта—DPC, после чего помещает его в эту очерС^
Помещение DPC в очередь DPC служит указанием ядру запросить пР°
граммное прерывание уровня диспетчерский/DPC. Так как обычно DPC поМе
щаются в очередь кодом, исполняющимся на более высоком IRQL, то запрошс*1
ное прерывание не возникает до тех пор, пока IRQL не снизится до уровня А'
или нижнего уровня. Обработка DPC изображена на рис. 7—9-
Глава 7. Ядро
Процедуры DPC исполняются “втихомолку”; иными словами, при сниже-
нии IRQL они вызываются независимо от того, какой поток в данное время яв-
ляется текущим. Так как потоки пользовательского режима исполняются на ниж-
нем IRQL, то имеется высокая вероятность того, что DPC прервет выполнение
обычного пользовательского потока. Это означает, например, что DPC может
исполняться в Вашем адресном пространстве и иметь доступ к Вашим ресурсам,
в то время как Вы не будете даже подозревать об этом. В связи с этим и из-за
того, что они исполняются на IRQL диспетчерский/DPC, DPC нс могут запраши-
вать выделение системных ресурсов или изменять содержимое виртуальной
£
К."
памяти позаимствованного ими потока. Они могут вызывать функции ядра, по
«Й не могут обращаться к системным сервисам, генерировать страничные ошибки,
к* создавать, объекты или ждать их. К счастью, DPC может быть вызван только сис-
L темным кодом, и корректность его поведения гарантируется ОС. (Драйверы
£; устройств также должны гарантировать правильность использования DPC.)
a' DPC предназначены в основном для использования драйверами устройств,
В но используются и ядром. Чаще всего ядро использует их для обработки истече-
& ния кванта времени. На каждом такте системных часов генерируется прерыва-
ние IRQL таймера. Обработчик прерываний таймера (исполняющийся на тай-
gмерном IRQL) обновляет системное время, после чего уменьшает счетчик, отсле-
Е живающий время исполнения текущего потока. Когда значение счетчика дости-
|С гает нуля, квант времени потока заканчивается, и ядру может потребоваться вы-
|г. полнить перепланировку загрузки процессора; эта низкоприоритетная задача
к должна выполнятся на IRQL диспетчерский/DPC. Обработчик прерываний тай-
ife. мера помещает в очередь DPC для инициирования планирования потоков и за-
bi'' вершает свою работу, понижая IRQL процессора. Так как прерывание DPC имеет
' Таблица распределения
*
Диспетчер вызывает каждую процедуру из очереди DPC.
в результате чего очередь становится пустой
Если нужно, диспетчер выполняет и перепланировку
загрузки процессора
Рис. 7-9. Доставка DPC.
СНОВЫ WINDOWS NT
Глава 7. Ядро
более низкий приоритет, чем прерывания от устройств, то все ожидаю,,
прерывания от устройств, которые будут демаскированы, обрабатываются /
того, как произойдег прерывание DPC.
Прерывания асинхронного вызова процедуры (АРС). Когда ;i.,
помещает в очередь объскт-DPC, генерируемое в результате этого прерыц;,,''
DPC вмешивается в выполнение любого потока. Иногда также бывает
иметь возможность прервать выполнение заданного потока и заставить его
полнить некоторую процедуру.
Для этого ядро предоставляет механизм, называемый асинхронным
вом процедуры (АРС). АРС могут помещаться в очередь как системным k<>,:(0S]
так и кодом пользовательского режима, хотя АРС режима ядра мощнее. Как(|
DPC, АРС выполняется асинхронно при наступлении соответствующих условие
Для пользовательских АРС такими условиями являются следующие:
© Текущим потоком должен быть тот, который предназначен для вывод,
нения данного АРС.
[RQL процессора должен быть на низшем уровне.
в Целевой поток АРС пользовательского режима должен объявить себя
оповещенным (обсуждается ниже).
АРС режима ядра, в отличие от АРС пользовательского режима, не требуют
для своего выполнения “разрешения” от целевого потока. Они могут прервать
поток и выполнить процедуру без его участия или согласия.
Программа помещает- в очередь АРС для некоторого потока, вызывая ядро
либо непосредственно (для системного кода), либо косвенно (для кода пользо-
вательского режима). Ядро, в свою очередь, запрашивает программное прерыва-
ние уровня АРС, и при выполнении всех вышеперечисленных условий целена)
поток прерываегся и выполняет данный АРС.
Как и DPC, АРС описываются управляющим объектом ядра, так назваемым
объектам-АРС. АРС, ждущие своего выполнения, находятся в управляемой ядр|)М
очереди АРС (АРС queue). В отличие от очереди DPC, являющейся общесистемной
очередь АРС специфична для потока — у каждого потока имеется своя собственна®
очередь АРС. При получении запроса на постановку' АРС в очередь ядро ставит еГ0
в очередь того потока, который должен выполнять процедуру данного АРС
Так как АРС исполняется в контексте заданного потока и на более низ»®’1
IRQL, к нему не применяются ограничения, налагаемые на DPC. Он может запря'
шивать ресурсы (объекты), ждат ь у описателей объектов, генерировать стран®’4'
ные ошибки и вызывать системные сервисы. Это делает АРС полезными даже
№
ИЙ-
'
ф
W
•те г
ад
•10'.;
i'4'т
7)
кода пользовательского режима.
Хотя код пользовательского режима не может непосредственно со.чда>’:,1Т
или помещать в очередь объскт-АРС. некоторые базовые сервисы NT приш*’’3
ют в качестве параметра процедуру' АРС пользовательского режима. Напри^
подсистема или DLL могут при установке таймера задать процедуру АРС
интервал таймера истечет, ядро направляет АРС обратно подсистеме, котор^
его выполняет. Если подсистема обеспечивает своим клиентским приложен1151.
доступ к средству АРС NT, то приложение может, например, использовать
для выполнения “сборки мусора” через регулярные интервалы. Точно так’
базовые сервисы NT принимают АРС в качестве необязательного параметра.
позволяет вызывающей программе выполнять эту процедуру по завершен1’
#•
И*
операции ввода-вывода. (Хотя подсистема Win32 не экспортирует АРС в своем
API непосредственно, она предоставляет доступ к этой возможности в функцг >ях
API ReadFileExQ и WriteFileEx().)
Хотя поток нс может заблокировать АРС режима ядра, он может запретить
доставку АРС пользовательского режима. Фактически поток должен явно обо-
значить свое желание полу'чать прерывание АРС пользовательского режима,
объявив себя оповещаемым. Он может сделать это либо ожидая у описателя
объекта и задав, что это ожидание — оповещаемое, либо явно проверяя наличие
него ждущих выполнения АРС. В обоих случаях, если АРС пользовательского ре-
жима ждет своего выполнения, то ядро прерывает (оповещает) поток, передает
управление процедуре АРС и возобновляет обычное выполнение потока по за-
вершении работы процедуры.
Исполнительная система NT использует АРС режима ядра для выполнения
некоторой задачи ОС, которое должно происходить в адресном пространстве (в
контексте) определенного потока. Опа может использовать АРС режима ядра,
чтобы заставить поток прекратить выполнение системного сервиса (например,
вследствие прерывания или для записи результата выполнения асинхронной опе-
рации ввода—вывода в адресное пространство потока). Подсистемы среды при-
меняют АРС режима ядра, чтобы заставить поток приостановить свое выполнение
или завершиться, а также для считывания или установки контекста исполнения
пользовательского режима. В гл. 8, “Система ввода—вывода”, мы вернемся к теме
АРС, так как они широко используются в NT при обработке ввода-вывода.
Распределение исключений
В отличие от прерывании, которые могут возникать непредсказуемо, исключе-
ния — это прямой результат выполнения программы. Microsoft С определяет
архитектуру' программирования, известную как структурная обработка исклю-
чений, которая обеспечивает приложениям унифицированную реакцию на ис-
ключения. Основные концепции, лежащие в основе структурной обработки ис-
ключений, были представлены в гл. 2, “Общие сведения о системе”. Данный под-
раздел рассматривает се с другой точки зрения: как ядро представляет исключе-
ние и что делает, когда оно возникает.
Все исключения, кроме тех, которые достаточно просты и обрабатывают-
ся непосредственно обработчиком ловушки, обслуживаются модулем ядра, дис-
петчерам исключений (exception dispatcher) (см. рис. 7-6). Этот модуль зависит
от архитектуры процессора, но написан па С. Задача диспетчера исключений
состоит в том, чтобы найти обработчик исключений, который может данное
исключение “устранить”. Ниже приведен список машинно—независимых исклю-
чений, определенных ядром:
it!.
Нарушение защиты памяти
Целочисленное переполнение
Деление на ноль и арифметике
с плавающей точкой
Отладочная точка останова
Недопустимая машинная команда
Отладочное пошаговое исполнение
Ошибка чтения страницы
Целочисленное деление на ноль
Переполненис/потеря значимости числа
с плавающей точкой
Ненормализованный операнд
с плавающей точкой
Неверное выравнивание данных
Привилегированная машинная команда
Нарушение сторожевой страницы
Исчерпание квоты файла подкачки
Некоторые из этих исключений перехватываются и обрабатываются я,»*
незаметно для пользовательских программ. Например, если во время выполие,
отлаживаемой программы встречается точка останова, то генерируется иск.ткк4
нис, которое ядро обрабатывает путем вызова отладчика. Некоторые друттц.
ключения ядро обрабатывает, возвращая вызывающей программе код oinii6Kl)
Некоторым исключениям позволено “нетронутыми’’ выходить обращ,
пользовательский режим. Например, нарушение защиты памяти или арпфМе. 1
ческое переполнение генерируют исключения, которые ОС не обрабатывас! т
таких исключений подсистема среда или приложение могут задать при гюмоцд
специальных конструкций языка высокого уровня блочные обработчики
кточений (frame based exception handlers). Microsoft С — это первый Комину
Microsoft, поддерживающий структурную обработ ку исключений, однако
ства обработки исключений Windows NT не зависят от- языка программирован^
Термин блочный обозначает связь обработчика iгсключагий с актнвпзацц
ей определенной процедуры. При вызове процедуры в стеке создастся стскивщ
фрейм, представляющий данную активизацию процедуры. Со стековым
мом может быть связан один или несколько обработчиков исключении, каждад
из которых защищает какой-либо блок исходного кода программы. Когда воз-
никаем исключение, ядро ищет обработчик, связанный с текущим стековым
фреймом. Если его нет, то выполняется поиск обработчика для предьщущеп)
фрейма и так далее, пока блочный обработчик исключений нс будет найден
Если найти обработ чик нс удается, то ядро вызывает собственные обработчики
исключений по умолчанию. (Обратите внимание, что обработка исключений
реализована по-разному для разных процессоров. Реализация /для Intel х86 при-
меняет подход, исподьзующий стековые фреймы, в то время как реализа! щя ди
MIPS R4000 — табличный метод.)
При возникновении исключения, будь оно явно возбуждено профаммой
или неявно оборудованием, в ядре происходит цепочка событий. Управление
передается обработчику ловушки, когорый создает кадр ловушки (также, как это
делается при обработке прерывания). Этот кадр позволяет ОС возобновить вы-
полнение с места возникновения исключения, если последнее было успешно
обработано. Кроме того, обработ чик ловушки создает запись исключения, кото-
рая содержит причину исключения и привходящую информацию.
Если исключение произошло в режиме ядра, диспетчер исключений про-
сто вызывает процедуру для поиска блочного обработчика, который бх/iei об-
служивать данное исключение. Так как необработанные исключения режн»1-’
ядра рассматриваются как фатальные ошибки ОС, то Вы можете счита ть, '|1<1
диспетчер всегда находит некоторый обработчик.
При возникновении исключения в пользовательском режиме диспетчер
исключений выполняет более сложные действия. Вы, вероятно, помните из г'1'*
“Процессы и потоки”, что подсистема среды может установить для каждого с°'
зданного ею процесса порт отладки и порт исключений. Они используются fl-n
ром при обычной обработке исключений, как показано на рис. 7-10.
Часто источниками исключений являются отладочные точки осгапи^1
Поэтому первым действием диспетчера исключений становится посылка соо1"1
щсиия (через LPC) в порт отладки, связанный с процессом, в котором произо"1'
ло исключение. Эго даст возмож! юсть пользователю манипулировать стру ктуР*1
ми данных и вводить команды отладчика.
Если порт отладки не зарегистрирован или отладчик не обработал нск.>|<г
чение, диспетчер исключений переключается в пользовательский режим и я1’1
лова /. ядро
Лч
Обработчик
ловушки
(Фрейм
~~ исключения.
клиентский —г
идентификатор
потока)
Диспетчер
исключений
Обработчики
исключений
Отладчик
(первый шанс)
Блочные обработчики
исключений
Отладчик
(второй шанс)
$
Подсистема
среды
<-
Обработчик
по умолчанию ядра
Рис. 7-10. Распределение исключения.
у
зываст процедуру поиска блочного обработчика исключений. Если обработчик
не найден или ни сдан из них не обработал исключение, то диспетчер исключе-
ний переключается обратно в режим ядра и снова вызывает отладчик, чтобы
пользователь мог предпринять дополнительные действия для отладки.
Если отладчик отсутствует и блочный обработчик не найден, ядро посыла-
ет сообщение в порт исключений процесса потока. Этот порт, если он существу-
ет, был зарегистрирован подсистемой среды, управляющей данным потоком.
Порт исключений дает подсистеме среды, которая, как предполагается, его про-
сматривает, возможность трансляции исключения NT в специфичный для дан-
ной среды сигнал или исключение. Например, когда POSIX получает от ядра
сообщение о том, что один из ее потоков сгенерировал исключение, эта подси-
стема посылает потоку, вызвавшему исключение, сигнал POSIX—типа.
Хотя подсистема POSIX по умолчанию связывает порт исключений с каж-
дым из своих процессов, другие подсистемы могут нс зарегистрировать порт
или не предпринять никаких действий, когда получат от ядра уведомление о
необработанном исключении в одном из процессов. Если обработка исключе-
ния продвинулась до этой точки и подсистема нс обслужила исключение, ядро
вызывает обработчик исключения по умолчанию, а он просто завершает про-
цесс, поток которого вызвал исключение.
7.3.4
Распределение вызовов системных сервисов
Как показано на рис. т-6. обработ чик ловушки ядра NT распределяет прерыва-
ния, исключения и вызовы системных сервисов. Обработка прерываний и ис-
ключений была темой предыдущих разделов, в этом же мы кратко рассмотрим
системные сервисы. Вызовы системных сервисов, генерирующие ловушки, —
которые в Windows NT рассматриваются как исключения — интересны с точки
зрения расширяемости системы. Способ реализации системных сервисов ядром
позволяет динамически добавлять к ОС новые сервисы в будущих версиях.
Всякий раз, когда поток пользовательского режима вызывает системный
сервис , ему вдруг разрешается выполнять привилегированный код ОС. Обычно
эго проклятие для (XL Поток пользовательского режима может “залезть” в струк-
туры данных ОС или перепутать содержимое памяти, повредив, таким образом.
Глава 7. Ядро
самой системе и другим пользователям. По этой причине процессоры <Хл~
предоставляют специальную команду только для системных сервисов. '
команда — syscall па процессорах MIPS и INT 2ЕЬ на Intel х8б - примет^1
если поток пользовательского режима вызывает системный сервис. Алплр^
генерирует ловушку и переключается из пользовательского режима в щ.’-
ядра. Когда это происходит, ядро копируе т значения параметров сервиса 113^'
ка пользовательского режима в стек режима ядра потока (чтобы пользой.
никак не мог их изменить) и затем выполняет системный сервис.
Как показано на рис. 7-11, для поиска системных сервисов ядро иы иГ(1,
ет таблицу распределения системных сервисов. Эта таблица похожа па табдщ
распределения прерываний, описанную выше, только каждый элемент ее содн.
жиг указатель на системный сервис, а не па процедуру обработки.
Использование таблицы распределения системных сервисов делает базоц-
сервисы NT расширяемыми. Поддержка новых сервисов добавляется в ядро про^,
путем расширения этой таблицы без изменений в ОС или в приложениях. 'Ic-орец
чески после создания кода нового сервиса системный администратор может пм
сто запустил» утилиту, которая динамически создаст новую таблицу распределен^
с дополнительным элементом, указываюгцим на новый системный сервис. Хотя,
первой версии Windows NT гге присутствуют ни эта возможность, ни сооттк-тегц.
ющий интерфейс пользователя, они могут быть добавлены в будущем.
Пользовательский
реже
Режим ядре
Многопроцессорная синхронизация
Концепция взаимного исключения (mutual exclusion) является критической
при разработке ОС. Она подразумевает, что в любой момент времени доступ к
данному ресурсу может иметь один и только один поток. Взаимное исключе-
ние необходимо, когда ресу[х? самостоятельно не поддерживает совместный
доступ или когда совместное использование может давать непредсказуемые
результаты. Например, если два потока одновременно копируют файлы в порт
принтера, результаты вывода могут перемешаться. Аналогично, если один по-
ток считывает область памяти в тот момент, когда другой в нее записывает,
первый поток получит непредсказуемые данные. В общем случае изменяемые
ресурсы не могут использоваться совместно без определенных ограничений,
тогда как для немодифицируемых ресурсов это допустимо. На рис. 7—12 пока-
зано, что происходит, когда два потока, выполняющиеся на разных процессо-
рах, выполнякхг запись в циклическую очередь.
Так как второй поток получает указатель на конец очереди до того, как
первый поток его обновит, второй поток поместит данные на то же место, что
и первый — затерев его данные и оставив одно место в очереди пустым. Обра-
тите внимание, что, хотя г га рисунке показан случай многопроцессорной систе-
мы, то же самое может произойти и на однопроцессорном компьютере, если ОС
«до, переключит контекст на второй поток, прежде чем первый обновит указатель
•
ЙГ
•
г
Л5
де
Вызов
^ис- 7-11. Исключения системных сервисов.
Системнь»'
сервис 2
lUfr.
да
л
Ugj
хвоста очереди.
Участки кода, в которых выполняется доступ к ресурсу, не поддерживаю-
щему совместное использование, называются критическими секциями (critical
sections). Чтобы гарантировать корректную работу, в критической секции может
одновременно выполнятся не более одного потока. Пока один поток записыва-
ет данные в файл, обновляет базу данных или модифицирует совместно исполь-
зуемую переменную, никакому другому потоку не разрешен доступ к тому же рс-
Время
Процессор
А
Процессор
В
Получить хвост очереди
Вставить данные в текущую позицию
Получить хвост очереди
Увеличить указатель хвоста
Вставить данные в текущую позицию/"ОШИБКА*/
Увеличить указатель хвоста
рис. 7-12. Некорректное совместное использование памяти.
Ы WINDOWS NT
урсу. Код па рис. 7-12 — критическая секция, в кото|эой некорректно, без il i;i
jmhofo исключения, (кущсствляется доступ к совместно используемым данным
Вопрос взаимного исключения, существенный для всех ОС., особенно |.;(
кен (и сложен) для тесно связанных (tightly- coupled) ОС ссиинетричной.иу ц,_
пипроцессорной обработкой (symmetric multiprocessing), таких как Window ч
МТ; здесь один и тот же системный код выполняется на нескольких процессорах
одновременно, совместно используя структуры данных в глобальной памяти. в ,
Windows NT предоставление механизмов, которые системный код испол1>:ЛГ|
кля предотвращения одновременной модификации структуры данных дг.у\1я
потоками, — это задача ядра. Ядро обеспечивает примитивы взаимного иск.ц<).
чения; оно и другие компоненты исполнительной системы используют их д.1я
синхронизации доступа к глобальным структурам данных.
Следующий подраздел описывает использование ядром взаимного исклю-
чения для защиты своих глобальных структур данных. Раздел, идущий за этим,
рассматривает механизмы взаимного исключения и синхронизации, которые
ядро предоставляет исполнительной системе, а та. в свою очередь — польз! жи-
тельскому режиму.
Синхронизация на уровне ядра
На различных стадиях работы ядро должно гарантировать, что в каждый момент
времени в критической секции исполняется один и т олько один процессор. Кри-
тические ccKiдии ядра — это сегменты кода, модифш (ирующис гл< юалытыс струк-
туры данных, например, базу данных диспетчера ядра или очередь DPC. (Операци-
онная сист ема нс будет работать нормально, если ядро не гарантирует, что пото-
ки осуществляют доступ к этим данным в режиме взаимного исключения.
Область, требующая самого большого внимания, — прерывания. Напри-
мер, в момент изменения ядром глобальной структуры данных может возник-
нуть прерывании, обработчик которого также изменяет эту структуру. Пр< <тыс
Однопроцессорные ОС иногда предотвращают такие случаи, запрещая прерыва-
ния на время доступа к глобальным данным, по ядро NT применяет более т» инах"
решение. Прежде чем использовать глобальный ресурс, ядро временно маек, iру-
ст те прерывания, обрабел чикп которых также используют этот pccvpc. .Ото де-
лается путем повышения IRQI. процессора до самого высокого уровня (и тех-
что используются источниками прерывании. ехтращающимися к глобальным
данным). Например, прерывание уровня диспетчерский/DPC. вызывает иенот
непис диспетчера, который обращается к базе данных диспетчера. Следован-11’'
по. любая .другая часть ядра, использующая эту базу данных, повышает П‘\'1.Д(!
отметки диспетчерский/DPC, маскируя прерывания этого ур< >впя перед ik поль-
зованием базы данных.
Такая стратегия п|юкрасно подходит для однопроцессорной системы. й*
неадекватна в многопроцессорной конфигурации. Повышение IRQL па одП*’'1
процессоре не предотвращает прерываний на других. Ядру также пеоб.хо п1'1*'
обеспечить взаимоисключающий доступ для нескольких процессоров.
Механизм, используемый ядром для достижения .многопроцсссорис л о
пмного исключения, называется (пин -блокировкой (spin lock), (лпш—блокщч,,!
на это механизм, связанный с |лобалыюн структурой данных, например о‘|1
редыо DPC скак на рис. 13)
Глава 7. Ядро
Прежде чем воГгш к показанную па рисунке критическую секцию, ядро дол-
жно получить eiiiiii -блокнретку. связанную с защищенной очередью 1)Р( 1-л'лн
блокир шка не свободна. то ядро пытается получить се, пока это не увенчается
успехом, (лпш -блокировка названа так нагому, что я.дро (и. следовательно. нр>-
цесеор) изолировано и “вращается само по себе"*, пока не получит блокировку.
(лпш блокировки, как и защищаемые ими структуры данных, располага-
ются в глобальной памяти. Код получения и освобождения спин блокировки
написан на языке ассемблера, чтобы повысить скорость работы и использовать
механизм блокировки. предехтагляемый данной архитектурой процессора. Во
многих архитектурах спин-блокировка реализована при помощи команды “про-
верить и установить”, которая судной (атомарной) операцией п|хсверяет значе-
ние переменной блокировки и захватывает блокировку. Проверка н захват од-
ной командой предотвращает захват блокировки вторым потоком (в интервале
времени между проверкой значения переменной и захватом блокировки пер-
вым потоком).
Когда поток пытается получить спин—блокировку, вся другая активность
на этом процессоре приостанавливается. Поэтому поток, получивший такую
блокировку, никоей нс вытесняется и имеет возможность продолжать выполне-
ние, чтобы быстрее ск'вободтгть ее. Ядро использует спин-блокировки с боль-
шой осторожностью, минимизируя количество команд, выполняемых во время
обладания ими.
('пин—блокировки доступны другим частям исполнительной системы че-
рез набор функций ядра. Драйверы устройств. например, используют спин—бло-
кировки для того, чтобы к регистрам устройств и другим глобальным данным в
любе>й момс! п' вре.мс! п 1 и мела доступ тс >лько с >Д1 ia часть драйвера (11 только с < мп to-
re процессора). Мы вернемся к этому вопросу в гл. 8. “Система ввода—вывода".
Процессор А
Процессор В
Do
Пытаться получить
спин-блокировку
очереди DPC
Until УСПЕХ
Удалить DPC из очереди
Освободить спин-блокировку
очереди DPC
Спин-
блокировка
DPC
DPC
Очередь DPC
Do
— Пытаться получить
спин-блокировку
очереди DPC
Until УСПЕХ
Begin
Удалить DPC из очереди
End
Освободить спин-блокировку
очереди DPC
Критическая секция
Рис. 7-13. Использование спин-блокировки.
U НСрС1«М< <- ЛИ IIHK spill <1Л1ЫЧЛС1 вря Hili шс"
ЬНОВЫ WINDOWS NT
1.2 Синхронизация на уровне исполнительной системы
Программному обеспечению за пределами ядра также необходима синхро,
зация доступа к глобальным структурам данных в многопроцессорной ср^'
Например, у диспетчера виртуальной памяти есть только одна база дац11ь^
страничных фреймов, с которой он работает как с глобальной структеро.
данных, а драйверам устройств нужна возможность монопольного Доступа
своим устройствам. При помогци функций ядра, исполнительная система Х1()
жст создавать, получать и освобождать спин—блокировку.
Однако спин-блокировки только частично удовлетворяют потребность ц
полнительной системы в механизмах синхронизации. Так как ожидание спиц,
блокировок буквально останавливает процессор, их можно использовать тСль
ко при следующих строгих условиях:
и Доступ к защищенному ресурсу должен осуществляться быстро ц
сложного взаимодействия с другим кодом.
М Критическая секция не может откачиваться из памяти, не может обра-
щаться к нерезидентным данным, не может вызывать внешние процеду-
ры (включая системные сервисы) и не может генерировать прерывания
и исключения.
Эти ограничения довольно серьезны и не всегда их можно удовлетворить
Более того, помимо взаимного исключения исполнительной системе необходи-
мо выполнять синхронизацию других типов, и она должна предоставить меха-
низмы синхронизации для пользовательского режима.
Рис. 7-14. Ожидание диспетчерского объекта.
Главе 7. Ядро
Ядро предоставляет исполнительной системе другие механизмы синхро-
низации в форме объектов ядра, которые называются диспетчерскими объекта-
ми. Поток может синхронизироваться с диспетчерским объектом путем ожида-
ния у его описателя. Это заставляет ядро приостановить поток и изменить его
состояние с “исполняющийся" па “ожидающий”, как показано на рис. 7—14. Ядро
изымает поток из очереди готовности диспетчера и более не рассматривает его
в качестве кандидата на выполнение.
Поток не может возобновить выполнение, пока ядро не изменит его состо-
яние с “ожидающий” на “готовый”. Такое изменение происходит, когда состоя-
ние диспетчерского объекта, у описателя которого ждет поток, изменится с “за-
нят” на “свободен” (например, когда какой-нибудь другой поток установит
объект-событие). Ядро отвечает за оба типа переходов между состояниями. Неко-
торые диспетчерские объекты ядра и системные события, вызывающие измене-
ния их состояния, показаны на рис. 7-15.
Каждый тип диспетчерского объекта предоставляет особый тип синхро-
низации. Например, объект-мьютекс обеспечивает взаимное исключение; сема-
фор работает как шлюз, через который может проходить переменное число
потоков, — это бывает полезно, когда имеется несколько идентичных ресурсов.
События могут использоваться либо для уведомления о том, что было выполне-
но некоторое действие, либо для реализации взаимного исключения. Пары со-
бытий — это средство поддержки ядром быстрого LPC, оптимизированной фор-
мы передачи сообщении в подсистеме Win32. Таймеры “срабатывают” по исте-
чении заданного интервала времени. Поток может задать завершения другого
потока, что бывае т полезно для координации действий между взаимодействую-
щими потоками. Все вместе, диспетчерские объекты ядра предоставляют испол-
нительной системе большую гибкость в синхронизации исполнения.
Синхронизационные объекты, доступные в пользовательском режиме (опи-
саны в гл. 4, “Процессы и потоки”), получают свои возможности синхронизации
от диспетчерских объек тов ядра. Каждый синхронизационный объект, видимый
полым жительскому реж! шу, инкапсулирует в себе по крайней мерс один диспет-
черский объект ядра. Приведенный ниже пример установки события демонст-
рирует взаимодействие синхронизации с планированием потоков:
1. Поток пользовательского режима ждет у описателя объекта—события.
2. Ядро изменяет состояние потока с “готовый" на “ожидающий”, после
чего помещает поток в список потоков, ждущих данное событие.
3. Другой поток устанавливает событие.
4. Ядро просматривает список потоков, ждущих события. Если для неко-
торого потока выполнены условия прекращения ожидания5, то ядро
изменяет его состояние с “ожидающий” на “готовый”. Если это поток
переменного приоритета, то ядро может также поднять его приоритет.
5. Так как к исполнению готов новый поток, то диспетчер выполняет пе-
репланировку: Если он находит выполняющийся поток, приоритет ко-
торого ниже приоритета нового потока, то низкоприоритетный по-
ток вытесняется путем генерации программного прерывания для нев-
ключения контекста па новый поток.
Некоторые потоки могут ждать несколько объектов сразу, гак что они продолжают ожидать.
Диспетчерский
объект
Изменение состояния
Воздействие сосм
"свободен" Л
ожидающие по.
Мьютекс
(используется только
в режиме ядра)
Поток-владелец
Поток, возобновивший
исполнение, захватывает
Ядро освобождав
ИЗ ЖДУЩИХ ПОтоцЯ.
мьютекс
Мутант
(экспортируется для
пользовательского
режима)
Поток-владелец
или другой поток
исполнение, захватывает
мутант
Ядро освобождаем
из ждущих ПОТОк^
Семафор
Один поток освобождает
семафор и ресурс
Занят Свободен
Поток захватывает семафор.
Меньшее количество ресурсов
остается доступно
Ядро освобождая
один или несколы®
ждущих потоков"
Событие
Поток устанавливает событие
Ядро возобновляет исполнение
одного или нескольких потоков
Ядро освобокдс®
один или несколько
ждущих потоков
Пара событий
Выделенный поток устанавливает
одно из событий пары
Занят • *> Свободен
Ядро возобновляет исполнение
другого выделенного потока
Ядро освобожден
ожидающий выделен^
поток
Таймер
Таймер срабатывает
Занят Свободен
Поток (пере)иницислизирует таймер
Ядро ОСВОбОЖА0®'
все ждущие пото1
Поток
Поток завершается
Занят *— _____— Свободен
Некоторый поток заново
инициализирует объект-поток
Ядро освобоЖА^
все ждущие по™
Рис. 7-15. Некоторые диспетчерские объекты ядра.
I 6. Если пи на одном из процессоров нельзя выполнить вытеснение, дис-
I петчер помещает готовый поток в свою очередь, чтобы направить его
Г на выполнение позднее.
» Восстановление после сбоя питания
Главной задачей при разработке Windows NT было сделать ее устойчивой и Ha-
г. дежной ОС. Здесь можно задать вопрос: насколько далеко должна заходить Ha-
rt дежность? Хо тя архитектура обработки исключений помогает защитить ОС из-
1 нугрп, что произойдет, если вмешается внешний фактор, нарушающий се цело-
стность? Одной из форм внешней угрозы являются пользователи—нарушители,
F пытающиеся обойти системный контроль доступа. Другая потенциальная угроза
» — программы, “сходящие с ума” и пытающиеся израсходовать все системные
*. ресурсы. Для борьбы с первой опасностью предназначена система защиты
Windows NT, а ограничения квот па ресурсы помогают бороться со второй.
? Однако остается еще одна опасность — сбой питания.
I' Для сбоя питания в ядре NT зарезервировано второе по старшинству’ при-
оритета прерывание. Оно уведомляет о проблеме в источнике питания, чтобы
система могла выполнить останов как можно более корректно. Если бы ни эта
процедура, вся работа, выполнявшаяся в момент аварии, могла бы пропасть.
^Исполняющиеся программы могут закончить или не закончить свою работу’ и
могут оставить постоянные ресурсы (такие как файлы), которые они использо-
вали, в восс тановимом или в невосстановимом состоянии.
При сбое питания у ОС остается время только на то, чтобы начать проце-
дуру останова. Если компьютер оборудован резервными батареями для памяти,
.данные можно восстанови ть, когда питание будет подано вновь. Выполнявшие-
ся задачи могут быть перезапущены либо продолжены, в зависимос ти от их со-
' стояния на момент сбоя. (Конечно, при отсутствии резервных батарей такое
. восстановление невозможно.)
ц Перезагрузки регистров и возобновления исполнения недостаточно для
> полного восстановления системы. Так как устройства ввода—вывода работают
независимо от остальной ОС, для восстановления после сбоя питания нм требу’-
[ ется следующая поддержка со стороны ядра:
Они должны быть переинициализированы, когда питание* восстановится.
Они должны уметь определять, имел ли место сбой питания.
Эти средства предоставляются двумя управляющими объектами ядра.
Объекты-уведапчения питания (power notify objects) позволяют драйверам
I устройств зарегистрировать процедуру' восстановления, которую ядро будет
В Вызывать при возобновлении питания. Драйвер устройства определяет, что дол-
’ Жна делать эта прог щдура; в общем случае она выполг гяет повторную иг гициали-
! зацию устройства гг перезапуск прерванных операций ввода—вывода.
Чтобы .зарегистрировать процедуру восстановления после сбоя питания,
драйвер создает объект -уведомление питания, вызывает ядро для ипициализа-
f ции о&ьскта указателем па процедуру, после чего снова вызывает ядро для до-
1 бавления объекта в очередь, контролируемую ядром. При восстановлен! ги г г ита-
I ния ядро просматривает эту очередь гг вызывает все процедуры по порядку.
Ядро предоставляет еще один управляющий объект, используемый
верами устройств. объект состояние питания (power status object), Ч?
такой объект и добавив его в другую очередь ядра, драйвер может опрсдел,^ *«
перед началом операции, которую нельзя прервать (например, запись flailllb/
в регистр устройства), не произошел ли сбой питания. Если он произоц1с, '
драйвер нс выполняет операцию. В гл. 8 содержится более подробная ш
мация по этим вопросам, связанным со вводом—выводом.
'Фер.
Заключение
Ядро NT — это стержень всей активности Windows NT. Оно управляет процС(.
сором, планируя потоки и направляя их на выполнение, реагирует на прерц.
вания и исключения и реализует низкоуровневые механизмы синхронизации
которые используются им самим и другими частями исполнительной системы
Другие модули исполнительной системы NT полагаются па функции и прими-
тивы, предоставляемые ядром; “поверх них’’ строится системная стратегия и
обеспечиваются различные возможности пользовательского режима.
Примитивы ядра включают группы объектов, инкапсулируемые в объек-
тах исполнительной системы. Управляющие объекты ядра обеспечивают реа-
лизацию разнообразных функций ОС, ’тогда как диспетчерские объекты ядра
— это примитивы с встроенными синхронизационными возможностями. Син-
хронизация, как внутри ядра, так и за его пределами, критична для корректно-
го функционирования ОС. Она особенно сложна на многопроцессорных ком-
пьютерах. Ядро синхронизирует свое собственное выполнение для правильно-
го функционирования, а предоставляемые им механизмы позволяют делать то
же самое остальным частям исполнительной системы.
Кроме выполнения других обязанностей, ядро обеспечивает поддержку
особого рода для системы ввода-вывода. Оно предоставляет объекты и функ-
ции, используемые драйверами устройств для синхронизации работы в много-
процессорной среде и для восстановления операций ввода-вывода после ава-
рии питания. Подсистема ввода—вывода и се взаимодействие с ядром NT более
подробно рассматриваются в следующей главе.
Г А А В A 8
СИСТЕМА ВВОДА-ВЫВОДА
Гхак отметил и книге “Fundamentals of Operating Systems” Листер: “Но традиции,
ввод—вывод считается одной из самых сложных областей проектирования ОС, в
которой сложно применить общий подход и где изобилуют частные методы.”' В
действительности источником сложности является огромное число устройств
ввода-вывода невероятно разнообразной природы, которые должна поддержи-
вать ОС. Перед проектировщиком системы ввода—вывода встает непростая зада-
ча — создать виртуальный интерфейс устройств ввода—вывода, позволяющий
программистам просто считывать или сохранять данные, не обращая внимание
на специфику7 устройства.
Система ввода—вывода, способная объединить в одной модели широкий
набор устройств, должна быть универсальной. Она должна учитывать потребно-
сти существующих уст ройств, от простой мыши до клавиатур, принтеров, гра-
фических дисплеев, дисковых накопителей, компакт дисков и даже сетей. Она
должна также поддерживать будущие технологии хранения н ввода данных.
Система ввода—вывода NT предоставляет унифицированный интерфейс высо-
кого уровня для операций ввода—вывода на уровне исполнительной системы и
изолирует прикладные программы от специфики физических устройств. Она
также избавляет остальную часть ОС от деталей работы с устройствами и таким
образом изолирует машинно—зависимый код и сокращает его объем.
Диспетчер ввода-вывода — унифицирующий компонент системы ввода-
вывода — разработан Дэррилом Хэвеисом (Darryl Havens), который имеет более
чем 12—леший опыт разработки и кодирования компонентов ОС. Ввод—вывод
Windows NT заимствует некоторые черты тех ОС, над которыми работа.'! Дэррш! —
в частности. ОС VAX/VMS и VAX ELN фирмы DEC. Поддержка Win32, OS/2 и
POSIX также определила некоторые требования, повлиявшие на конструкцию
системы ввода—вывода.
Цели проекта сист емы ввода-вывода сост ояли в следующем,-
Предост авить поддержку нескольких устанавливаемых файловых сис-
тем (installable file systems), включая FAT, высокопроизводительную
файловую систему (HPFS), файловую систему' компакт-дисков (CDFS) и
файловую систему NT (NTFS) — новую, полностью восстанавливаемую
файловую систему.
1 А. М. Ijsicr. t imclamenlals of Operating Systems (Nev. York- Springer-Vcrkig, 1984), G A.
Глава 8. Система ввода-вывода
системам и драйверам устройств. Диспегчер в действительности не управляет
вводом-выводом. Его работа создать IRP, который используется для пред-
ставления операции ввода-вывода, передать пакет соответствующему драйве-
ру’ и удалить по завершении операции ввода—вывода. В противоположность это-
му; драйвер получает 1RP, выполняет указанную в нем операцию ввода—вывода н
либо возвращает его обра тно диспетчеру’ ввода-вывода для завершения обработ-
ки, либо передает для продолжения другому драйверу’ (через диспетчер).
В системе ввода—вывода NT термин драйвер (driver) употребляется в более
широком смысле, чем обычный термин драйвер устройства (device driver).
Файловые системы NT —- это тоже драйверы “устройств”, но более сложные, они
принимают запросы ввода—вывода и обрабатывают их, выдавая более конкрет-
ные запросы к драйверам физических устройств. Взаимодействие между драй-
верами файловых систем и драйверами устройств осуществляется посредством
передачи IRP.
В дополнение к созданию и удалению IRP, диспегчер ввода-вывода предо-
ставляет реализации процедур, общих для разных драйверов. Драйверы обраща-
ются к этим процедурам во время обработки ввода—вывода. Благодаря объеди-
нению общих задач в диспетчере ввода—вывода, отдельные драйверы становят-
ся проще и компактнее. Например, диспетчер предоставляет функцию вызова
драйвером других драйверов. Он также управляет буферами для обработки за-
просов ввода-вывода, предоставляе т драйверам поддержку тайм-аутов и сохра-
Подсистемс
среды
или DLL
Пользовотельский
режим
Режим ядра
Драйверы сети
и файловых систем
Мышь Видеодисплей Принтер
и клавиатура
Рис. 8-1. Части системы ввода-вывода.
Дисковое
устройство
Привод
компакт-диска
Накопитель
на магнитной
ленте
Сетевое
устройство
239
пяст информацию о том, какие устанавливаемые файловые системы в данный
момент загружены.
Помимо этого, диспетчер ввода вывода предоставляет гибкие средства,
позволяющие подсистемам среда, таким как Win32 и POSIX, реализовывать своп
API ввода-вывода. Сервисы, предоставляемые диспетчером ввода вывода, име-
ют широкие функциональные возможности, позволяющие поддерживать раз-
личные схемы ввода—вывода пользовательского режима.
2 Особенности архитектуры
Структура системы ввода вывода NT сложилась как результат одновременного
следования традициям и решения вновь возникающих задач. Обратная совмес-
тимость является важным соображением при разрабтхгке ОС. За исключением
редкого случая создания революционно повой ОС, система должна быть совме-
стима или, по крайней мере, способна к взаимодействию с существующими си-
стемами. Особенно важна обратная совместимость для системы ввода—вывода.
Пользователи компьютеров обычно обновляют программное обеспечение чаще,
чем покупают новое оборудование. Хотя новая ОС может потребовать установ-
ки дополнительной памяти или увеличения объема дискового пространства, она
только в крайнем случае можег требовать покупки жесткого диска новой модели
или замены дисплея. Это означает-, что система ввода вывода должна i icnpeMei i
но поддерживать старые и даже “древние” устройства.
'Гем не менее, Windows NT — это ОС, предназначенная для работы па са-
мых современных процессорах, использующих технологии 90—х годов. Учесть
разнородные п архаичные требования в рамках целостной, общей модели было
одной из самых сложных задач при разработке системы ввода—вывода. Другой
задачей было создать систему, которая не была бы простым “наименьшим об-
щим кратным’’ устаревших технологии, по которая отвечала бы требованиям
будущего п хорошо стыковалась с остальной частью ОС. В следующих разделах
описаны некоторые определяющие характеристики модели ввода вывода NT.
1 Объектная модель NT
В свое время ОС I’NIX определила новый, упрощенный подход к вводу—выводу.
В его рамках все считываемые или записываемые данные рассматриваются про-
сто как поток байтов, направляемый в виртуальные файлы, которые представ-
ляются файловыми дескрипторами. Вгфтусаьиый файл (virtual file) обознача-
ет любой источник пли приемник ввода—вывода, работа с которым идет гак,
как если бы он был файлом. ОС определяет, является ли “файл” консольным
терминалом, каналом или настоящим файлом па диске, и направляет данные в
нужное место.
В 'Windows NT программы также осуществляют ввод вывод в виртуальные
файлы, манипулируя ими посредс твом описателей файла (file handles). Концеп-
ция описа теля файла не нова, по в исполнительной системе NT описатель файла
фактически ссылается на файловый объект (file object) исполнительной систе-
мы. Все возможные источники или приемники ввода вывода представлены фай
новыми объектами. Потоки пользовательского режима вызывают базовые сер-
висы файлового объекта NT для чтения из файла, записи в файл и выполнения
других операций. Диспетчер ввода-вывода динамически преобразует эти за
просы к виртуальным файлам в запросы к настоящим файлам, каталогам фай-
лов, физическим устройствам, каналам, сетям, почтовым ящикам и любым дру-
гим местам назначения, которые только могут возникнуть в будущем.
Как и в других ОС. приложение открывает файл, используя стандартную
библиотечную функцию какого-либо языка профаммирования, например С. В
ответ оно получает (в той пли иной форме) описатель файлового объекта ис-
полнительной системы NT. Например, когда приложение Win32 вызывает функ-
цию fopcn(), библиотека С обращается к функции API Win32 CreateFile(), кото
рая, в спою очередь, вызывает объектный сервис ввода-вывода NT. Диспетчер
ввода—вывода открывает файловый объект и возвращает описатель объекта биб-
лиотеке С, которая передает его прикладной программе (рис. 8-2).
Источники и приемники ввода-вывода представлены в виде объектов, так-
как они удовлетворяют определению обтекта Windows NT: это системные ре-
сурсы, которые могут совместно использоваттюя потоками двух или более про-
цессов пользовательского режима. Файловые объекты, как и другие объекты,
имеют иерархические имена, охраняются объектной защитой, поддержииакхг
синхронизацию и обрабатываются объектными сервисами.
~ ~ Диспетчер
ввода-вывода
Файловые системы |
Диспетчер кэша |
Драйверы устройств |
(4) Создсп * Диспетчер объектов гь файловый о Справочный монитор защиты зъект (б) 1 Диспетчер процессов г— Зернутъ описс Средство локального вызова процедур — этель объекта. Диспетчер виртуальной памяти
Сетевые драйверы
Ядро
Слой абстрагирования от оборудования (HAL)
Рис. 8-2. Открытие файлового объекта.
ОСНОВЫ WINDOWS NT
Открывая файл, пользователь задает имя файла и необходимый тип досту-
па —- обычно чтение, запись, добавление или удаление. Данный запрос переда-
ется подсистеме среды (или DLL), которая обращается к системному сервису NT
Это инициирует поиск имени диспетчером объектов. Как утке было описано в
гл. 3, диспетчер объектов начинает поиск в своем пространстве имен, после
чего передает управление диспетчеру ввода-вывода, который и отыскивает
файловый объект.
Как и другие объекты исполнительной системы, файловые объекты защи-
щены дескриптором защиты, содержащим список управления доступом (ACL).
Когда поток открывает файл, диспетчер ввода-вывода обращается к подсистеме
защиты, чтобы определить, разрешает ли ACL файла процессу доступ запрошо i-
ного типа. Если доступ разрешен, диспетчер объектов предоставляет его и свя-
зывает предоставленные права доступа с возвращаемым описателем файла. Если
данный или другой поток процесса собирается выполнять дополнительные опе-
рации, не указанные в первоначальном запросе, поток должен открыть другой
описатель, что вызывает новую проверку прав доступа (более подробно о защите
объектов см. гл. 3, “Диспетчер объектов и контроль доступа”).
Файловые объекты используются также для синхронизации. После выдачи
запроса на ввод-вывод поток может ждать у описателя объекта, чтобы синхрони-
зировать свое выполнение с окончанием передачи данных дисководом или дру-
гим устройством. Эта возможность синхронизации тесно связана с другой осо-
бенностью системы ввода-вывода — асинхронными операциями ввода-вывода.
8.1.2.2 Унифицированная модель драйвера
Второй отличительной чертой системы ввода—вывода являе тся унифицирован-
ная структура ее драйверов и широкая интерпретация понятия “драйвер”. В ис-
полнительной системе NT драйвер устройства и файловая система строятся и
выглядят для остальной части ОС одинаково. Более того, именованные каналы и
сетевые редиректоры (программное обеспечение, направляющее запросы к фай-
лам по разным сетям) рассматриваются как “файловые системы” и реализованы
в виде соответствующих драйверов. Каждый драйвер — автономный компонент,
который можно добавлят ь к ОС и динамически из нее удалять.
Диспетчер ввода-вывода определяет модель построения драйверов. Ос-
новные характеристики этой модели таковы:
• Драйверы переносимы и написаны на языке высокого уровня. Они раз-
работаны так, чтобы при переносе с одной архитектуры процессора на
другую изменений не требовалось или они были минимальны. Драйве-
ры верхнего уровня, такие как файловые системы, вообще не требуют
изменений.
Операции ввода-вывода управляются пакетами и организуются на ос-
нове передачи IRP от одного драйвера другому. По мере их прохожде-
ния через различные слои системы ввода-вывода IRP могут использо-
ваться повторно.
Сист ема ввода—вывода може г динамически назначат ь драйверы для уп-
равления дополнительными или новыми устройст вами при изменении
koi 1фигурации системы.
242
Глава 8. Система ввода-вывода
Драйверы должны синхронизировать свой доступ к глобальным дан-
ным. В ходе работы драйвер может быт ь вытеснен потоками более вы-
сокого приоритета или прерван высокоприоритетными прерывания
мн. Это обстоятельство, как и то, что NT может выполнять код драйвера
на нескольких процессорах одновременно, требует особого внимания
к синхронизации.
Драйверы должны корректно восстанавливаться после сбоя питания и
перезапускать прерванные операции ввода—вывода2.
Унифицированный, модульный интерфейс, предоставляемый драйверами,
позволяет диспетчеру ввода-вывода “не видеть” их структуру или внутренние
детали. Драйверы могут также вызывать друг друта (через диспетчер ввода—вы-
вода), что обеспечивает независимую обработку запроса ввода—вывода на не-
скольких уровнях. Рассмотрим следующий пример. Файловая система получает
запрос па считывание символов из некоторого файла. Она транслирует перво
начальный запрос в запрос на последовательное считывание определенного ко-
личества байтов, начиная с некоторого “логического” адреса па диске. Этот за-
прос опа передает обычному драйверу диска. Последний, в свою очередь, транс-
лирует запрос в форму “цилшадр/дорожка/ссктор” и позиционирует- головки
диска для считывания данных. Такая способность располагать драйверы слоями
один над другим обеспечивает модульность и повышает степень повторного ис-
пользования кода.
Послойная модель ввода-вывода поддерживает произвольное количество
драйверов. В случае однослойной модели запрос на ввод вывод поел упаст дис-
петчеру и затем к .драйверу устройства, который непосредственно работает с
устройством, как показано на рис. 8—3.
Мышь
Драйверы устройств
Дисплей Клавиатура Принтер
Рис. 8-3. Ввод-вывод с однослойным драйвером.
Ото нс предполагается реализовать в первых версиях драйверов NT, по может быт ь добавлено в
будущих.
243
Жесткий
диск
Привод
компакт-диска
Сетевое
устройство
Рис. 8-4. Ввод-вывод с многослойным драйвером.
На рис. 8—1 показан пример многсх’лонного/цэапвера; здесь запрос прохо-
дит через несколько драйверов. В данном примере имеется два уровня: драйвер
файловой системы и драйвер устройства. Обрати те внимание, что драйвер верх-
него уровня нс вызывает нижележащий драйвер напрямую. Вместо этого он обра
щается к /цюпстчсру ввода—вывода, который и вызывает драйвер ниж| icro урс >bi 1я.
Многослойные драйверы встречаются чаще однослойных, хотя доступ к
некоторым простым, байт—ориентированным устройствам, напрп.мср, последи
нательным и параллельным портам, может осуществляться и однослойным.
Доступ к запоминающим устройствам большой емкости всегда выполняет-
ся при помощи многослойного драйвера. Сначала запрос проходит через драй-
вер файловой системы, а потом через драйвер устройства. Могут быть созданы
и более сложные наборы послойных драйверов. Например, в системе может
быть несколько устройств, таких как диски или ленты, подсоединенных к шине
SCSI (произносится “сказн”, расшифровывается как Small Computer System Inter
face -- Системный интерфейс для небольших компьютеров). Запрос ввода-вы-
вода к подобному дисковому накопителю проходит через следующие драйверы:
драйвер файловой системы,
драйвер класса дисков, который выдает запросы SCSI;
драйвер порта SCSI. посылающий запросы диску с использованием
протокола шины SCSI.
Все эти драйверы модульные, поэтому каждый из них может испол1>зоват1>-
ся и в другой конфигурации.
8.1.2.3 Асинхронная обработка
Грсты-п особенностью системы ввода—вывода NI является ее асинхронная при-
рода. Асинхронный ввод—вывод (asynchronous I/O) проще всего определить, они
сан сначала его противоположность: синхронный внод-вывод (synchronous I/O).
Большинство программистов хорошо знакомь! с синхронным вводом-выводом.
Вы вызываете сервис ввода-вывода; устройство заканчивает передачу данных и
возвращает Вашей программе код завершения; программа может сразу же ис-
пользовать переданные данные. В простейшем случае функции API ReadFilc() и
WriteFile() выполняются синхронно. 1(режде чем возвратить управление вызываю-
щей программе, они заканчивают выполнение операции ввода-вывода (рис. 8-5).
Синхронный ввод—вывод является стандартным для большинства ОС. и но
многих случаях этого достаточно. Однако современные процессоры невероят-
но быстры — гораздо быстрее большинства устройств ввода—вывода. Пока уст-
ройстве! обрабатывает один запрос, процессор может выполнить тысячи строк
кода. В идеале у приложения должна быть возможность использовать процес-
сор, пока устройство пересылае т данные. По этим соображениям диспетчер вво-
да-вывода предоставляет также и средства асинхронного ввода-вывода. Подси-
стема самостоятельно выбирает для себя синхронный пли асинхронный ввод-
вывод п. в зависимости ог поведения ее API, может предоставить своим клиент-
ским приложениям ввод-вывод обоих типов. Процедуры доступа к файлам API
Win32 могут исполняться как синхронно, так и асинхронно.
Асинхронные сервисы позволяют приложению выдать запрос ввода-вы-
вода п продолжать свою работу, пока устройство передает данные (рис. 8-6).
Асинхронный ввод-вывод имеет важное преимущество перед синхрон-
ным — возможность повышения скорости работы приложений. Пока устрой-
ство занято пересылкой данных, приложение продолжает выполнять другую ра-
боту. Например, оно может выводить изображение на монитор, пока драйвер
Приложение
\Л/п1еЯ1е(огмсатель_файла,---------- <>Кдет-----------Реас1Е|1е(описатель_файла,
данные,...) завершения обработки> данные....)
Подсистема
Win32
Вызвать ПТ сервис
записи в файл
Вернуть данные
Диспетчер
ввода-вывода
Драйвер
устройства
Устройство
Время
Пользовательский
режим
Режим ядра
Проверить параметры
Создать IRP
Вызвать драйвер устройства
Завершить IRP
Возврат
Направить запрос
Обработать
на устройство прерывание
Выполнить передачу данных
Прерывание для обслуживания
Рис. 8-5. Синхронный ввод-вывод.
945
устройства заполняет буфер данными из дискового файла. Чтобы использовать
асинхронный ввод-вывод, ноток должен указать это (в терминологии Win. >
“асинхронный” ввод-вывод называется “совмещенным” — “overlapped”) при от.
крытип описателя. После начала асинхронной операции ввода-вывода п<гп)1;
должен позаботиться о том, чтобы не использовать никаких данных этой опера-
ции до тех пор, пока драйвер устройства не завершит се. Другими словами, по-
ток должен синхронизировать свое выполнение с завершением операции вво-
да—выво/ia, ожидая у описателя файла, как показано на рис. 8—6.
Приблизительно треть базовых сервисов NT, предоставляемых подспс ,t-
мам диспетчером ввода-вывода, асинхронны но умолчанию. Асинхронными сер-
висами являются те, которые, вероятно, будут выполняться долгое или всхюц.с
непредсказуемое время — например, чтение или запись файла пли перебор со-
держания каталога файлов. Ноток, вызывающий эти сервисы, должен еппхрь
низировать снос выполнение с их завершением. Альтернативно, поток может
заставить все сервисы NT ’‘вести себя" синхронно, задав синхронный ввод вы-
вод при открытии описателя файла.
Есть различие .между тем, как сервис выглядит для вызывающей его про-
граммы, и тем, как он (фактически реализован системой ввода-вывода NT. Х-. bi
некоторые сервисы ведут себя синхронно, а некоторые асинхронно, сама . п-
стема ввода-вывода работ ает полностью асинхронно си обработки прерыва-
ний до передачи результатов обратно пользовательскому режиму и затека
исполнения запроса па устройстве. Асинхронный режим обеспечивает систе-
ме ввода- вывода возможность гибко переключаться на другие задачи, пока <т-
Приложение
\Л/п1еВПе(описатель файла, -- «Выполняет другую •• • «Ожидание закончено?
РеабН1е(огисотель_фой;
данные..
совмещений)
данные... работу?
совмещенный) \Л/аИ(описатель_файла)
Подсистема
Win32
Вызвать NT сервис
записи в файл
Вернуть код завершения
"ввод-вывод выполняется"
Диспетчер
вода-вывода
Драйвер
устройства
Устройство
1емя
Режим яд: с
Пользовательс кий
режим
Возврат
Проверить параметры
Создать IRP
Вызвать драйвер
устройства
Завершить IRP
Установить описатель фс,;’'.о
в сигнализированное
состояние
Направить запрос
на устройство
Возврат
Обработать
прерывание
Выполнить передачу данных
Прерывание для обслуживания
Рис. 8-6. Асинхронный ввод-вывод.
46
поситечыго медленные устройства пересылают данные. Асинхронные вызовы
процедур (АРС) другое средство NT и асинхронного ввода-вывода Win32
описаны в разделе 8.2.2..3.
8.1.2.4 Проекционный файловый ввод-вывод и кэширование файлов
ГЦюекцштный файчоаый в«од-«ъшод (mapped f ile I/O) это важней* средство
системы ввода—вывода, обеспечиваемое совместной работой этой системы н
диспетчера виртуальной памяти. Сама ОС использует проекционный ввод-
вывод для выполнения важных функций, таких как кэширование файлов пли
загрузка и выполнение программ. Диспетчер виртуальной памяти также дела-
ет проекционный ввод-вывод доступным пользовательскому режиму через
базовые сервисы. Подсистемы среды могут использовать эти сервисы для
предоставления средств проекционного файлового ввода-вывода своим кли-
ентским программам.
Проекционный ввод—вывод позволяет рассматривать файл, находящийся
надиске, как часть виртуальной памяти процесса. Программа может выполнять
доступ к файлу как к большому массиву; не прибегая к буферизации данных или
явному дисковому вводу—выводу. Программа просто должна обратиться по оп-
ределенному адресу памяти, а диспетчер виртуальной памяти использует свой
механизм подкачки для загрузки нужной страницы из дискового файла. Если
приложение выполняет запись в свое адресное пространство, то эти изменения
записываются диспетчером виртуальной памяти на диск в ходе обычной откач-
ки страниц.
Приложения, выполняющие большой обьем ввода—вывода или осуществ-
ляющие доступ к большому числу' разных файлов, потенциально могут повы-
сить скорость своей работы, используя проекционный ввод- вывод, так как за-
пись в память гораздо быстрее записи па диск. Кроме того, диспет чер виртуаль-
ной памяти оптимизирует свой доступ к диску; поэтому’ приложения, используя
проекционный ввод—вывод, получают и это преимущество.
Компонент системы ввода-вывода, называемый диспетчерам кэша, при-
меняет проекционный ввод-вывод для управления своим кэшем в памяти. Фай-
ловые системы и сетевой сервер Windows NT используют этот кэш для размеще-
ния в памяти часто требуемых данных, чтобы снизить время отклика для про-
грамм, выполняющих много операций ввода-вывода. Чогда как большинство
систем кэширования выделяют в памяти файловый кэш фнксироваг того разме-
ра, кэш NT растет или уменьшае тся в зависимости от объема доступной памяти.
Когда поток открывает и использует файл, файловая система обращается к дис-
петчеру кэша для создания неименованного объекта-секции и отображения и
него файла; Когда же вызывающая программа использует файл, диспетчер вир-
туальной памяти переносит страницы, к которым осуществляется доступ, с дис-
ка в объект-секцию н обратно на диск в ходе подкачки. Средство подкачки ав-
томатически расширяет размер кэша (используя обычные механизмы рабочего
набора), если доступно много памяти, и уменьшает его, если необходимы сво-
бодные страницы. Используя систему' подкачки страниц диспетчера виртуаль-
ной памяти, диспетчер кэша избегает дублирования этой работы.
’ Кэш NT, следовательно, состоит из набора обк'ктов—секций. Диспетчер кэша использует ипутрен-
цис структуры данных для учета различных секций и поиска данных в кэше.
2 Обработка ввода-вывода
В предыдущем разделе представлен взгляд па систему ввода—вывода NT “снару-
жи’’ п описаны основные се особенности. Следующим шагом будет путешествие
внутрь. Так как именно это и делают IKP, мы как бы последуем за ними.
Запросы ввода—вывода проходят несколько четко определенных этапов об-
работки. Эти этапы различаются, в зависимости от того, направлен ли запрос
к устройству, управляемому однослойным драйвером, или он проходит через
многослойный драйвер. Дальнейшие различия в обработке определяются задан-
ным типом ввода—вывода — синхронным или асинхронным.
Большинство запросов начинают свой путь одинаково. После открытия
описателя файла приложение вызывает некоторую процедуру ввода-вывода
Эга процедура обычно предоставляется библиотекой языка программирования
или подсистемой среды. Прстраммнст в Win32, например, может вызвать либо
функцию С read(), либо API Win32 ReadFilc(). В любом случае подсистема Win32
(или 1)1.1.) вызывает базовую функцию системы ввода-вывода.
Хотя подсистемы среды могут представлять описатели файлов различны-
ми способами, в основе большинства описателей пользовательского режима ле-
жит описатель объекта NT. Файлы в NT представляются как объекты, и подсисте-
ма ввода—вывода предоставляет объектные сервисы доя работы с ними. Паше
путешествие по системе ввода—вывода i шчнется с описания файловых объектов
NT и их базовых сервисов. Во втором разделе описывается, что происходит при
вызове системы ввода—вывода NT на примере запроса к устройству, которым
управляет (с использованием прерываний) однослойный драйвер. В третьем раз-
деле обсуждение распространяется на многослойные драйверы, и разбираемся
прохождение запроса ввода—вывода через несколько драйверов. Последний раз-
дел посвящен вопросам программирования, связанным с использованием асин-
хронных сервисов ввода—вывода.
2.1 Файловые объекты
Хотя совместно используемые ресурсы в Windows NT располагаются обычно в
памяти, большинство ресурсов, контролируемых системой ввода—вывода, либо
расположены на физнчесгаix устройствах, лг гбо caMi i являются таковым! i. Нсс.м<*г-
ря па это различие, совместно используемые ресурсы системы ввода-вывода, как
и других компонентов исполнительной системы, представлены в виде об'ккгов.
Объекты, управляемые системой вво/га—вывода, требуют особой обработ-
ки, так как диспетчер объектов знает нс очень много о структурах ката.кч>’И
файловых систем и еще меньше о форматах хранения данных на диске или
ленте. Из за этих и других сложностей, связанных с использованием физичек
кпх устройств, одной из основных проблем при создании системы ввода выг-о-
да была интеграция в систему объектов.
Файловые объекты являются промежуточными. Они i подставляют намя'И1
совмест но используемые физичес кие ресурс ы1. Когда программа открываст файл
или простое устройство, диспетчер ввода вывода возвращает описатель фай.1>>-
1 Иск(лч>рыс совместно используемые ресурсы системы ввода-вывода, такие как именованные kjh.i
лы и почтовые ящики эго ряс-положе! iih.il в памяти, а пе физические ресурсы. Они также пред
ставлены в сип емс вво. и вывода NI как объекты
Тип объекта
Файл
Атрибуты тела объекта
Сервисы
Имя файла
Тип устройства
Байтовое смещение
Режим разделения
Режим доступа
Диспозиция файла
Создать файл
Открыть файл
Читать файл
Писать в файл
Запросить информацию файла
Установить информацию файла
Опросить расширенные атрибуты
Установить расширенные атрибуты
Заблокировать диапазон байтов
Деблокировать диапазон байтов
Отменить ввод-вывод
Сбросить буферы на устройство
Опросить файл каталога
Уведомить об изменении содержимого каталога
Получить информацию тома
Установить информацию тома
Рис. 8-7. Файловый объект.
вого объекта NT. Диспетчер объектов рассматривает файловые объекты так же,
как и прочие, пока ему не понадобится получить или сохранить некоторую ин-
формацию на устройстве. В этот момент диспетчер объектов обращается к дис-
петчеру ввода—вывода для доступа к устройству. (Более подробно см. гл. 3. “Дис-
пегчер объектов и контроль доступа”). 11а рис. 8-7 раскрывается содержание поня-
тии файловых объектов и показаны сервисы, работающие сними (а. следователь-
но, и с открытыми файлами или физическими устройствами, которые эти объек-
ты представляют). В табл. 8—1 приведены атрибуты файлового объекта.
'Гак как файловый объект сам по себе нс ресурс, а представление совмест-
но используемого ресурса в памяти, он отличается от других объектов исполни-
тельной системы. Файловый объект содержит только данные, связанные с опи-
сателем объекта, в то время как совместно используемые данные пли текст со-
держатся в самом файле. Всякий раз. когда некоторый поток открывает описа-
тель файла, создастся новый файловый объект с новым набором атрибутов, спе-
цифичных для описателя. Например, атрибут “байтовое смещение” обозначает
то место в файле, с которого начнется следующая операция чтения или записи
(выполняемая с использованием данного описателя). С каждым описателем дан-
ного файла связано собственное байтовое смещение, .хотя все они и ссылаются
на один файл. Фактически атрибуты файлового обьекта можно считать относя
щимпся к описателю, как показано на рис. 8-8.
vv IISI UUW5
Таблица 8-1. Атрибуты файлового объекта
Атрибут
Имя <]KllL'ia
Т пн xcrpoiKTiu
Байтовое смещс 111 ic
Режт1 м разделе! шя
Режим доступа
Диспозиция файла
Назначение
Илей гифицирхс! физический файл, с которым связан
файловый обьс кт
Указывает тип устройств. па котором расположен ф.,_.,
Определяет текущее положение в файле (иепользхсц
только для синхронного ввода-вывода)
Указывает, мшут ли другие открывать фате! .тля чтения
записи или удаления, пока открыт этот описатель
Указываем будет ли ввод вывод синхронным или
асинхронным, k3iuh|X>b.iiiiii>i.m пли нс кэшированным
последовательным или произвольным и т. д.
Определяет, должен ли файл быть удален после стт> закрынщ
Хотя описатель файла уникален для процесса, соответствующий е.м\ фай,-,
таковым не является^ Таким образом, как и в случае любого совместно нсиоль-
зусмою ресурса, потоки должны синхронизировать свой доступ к совместно
используемым файлам. каталогам или устройствам. Например, если поток наме-
рен выполнять запись в файл, он должен задать монопольный доспи при от-
крытии описателя файла, чтобы предотвратить запись в файл со стропы дру-
гих потоков. Кроме того, он может заблокировать некоторую област ь файла на
время записи.
* Файловый 061,екч i:ucaa \ ннк.гк-п для процесса. кроме icx случаев, когда проще с д\6лир\сг <11 ’ ",|11
сачель для другого процесса или кся да дочерний процесс наследует оннсачель оi род пчелы koi 1 *
зти\ сл\ча.я\ два процесса имена ра 1ныс опис а 1ели, ссылающиеся на один и чот же файловый о6ьЧ‘’
[лаве 8. Система ввода-выводсг
Если «писатель ссылается на физический файл (а нс устройство, канал или
другой “файл”), поток может использовать описатель файла для получения ин-
формации как из файлового объекта. так и 113 самого файла. В табл. 8-2 показана
(частично) информация, которая хранится в файле (или в каталоге файлов, где
требуется по смыслу) в дополнение к данным, находящимся в файловом объек-
те. Эта информация зависит от файловой системы. NTES и HPFS определяют,
помимо указанных, еще и расширенные атрибуты.
Таблица 8-2. Атрибуты файла
Атрибут Назначение
Время создания У казывает дату и время создания файла
Время последнего Указывает дату и время, когда последний раз
доступа производилось чтение пли запись в файл
Время последней модификации Указывает дату и время последнего изменения файла
Время последнего изменения времени Указывает дату и время последнего изменения времени
Характеристики файла Указывает, является ли файл файлом “только для чтения", системным, скрытым, архивным или управляющим файлом
Размер файла Задает размер файла в байтах
Конец файла Отмечает смещение первого свободного байта в файле
Запрос ввода-вывода к однослойному драйверу
Задача диспетчера ввода-вывода состоит в том, чтобы получить запрос ввода-
вывода, использовать полущенный описатель файла для обработки запроса и
возвратить результат вызывающей программе. Для иллюстрации обработки за-
проса ввода-вывода исполнительной системой NT мы рассмотрим путь пакета
IRP от входа до выхода из системы ввода—вывода. В первом примере ниже про-
грамма пользовательского режима, например, подсистема среды пли DLL, выда-
ет запрос ввода-вывода к простому устройству, управляемому по прерываниям.
Устройство контролируется однослойным драйвером.
Обработка синхронного запроса проходит в три этапа:
1. Диет ютчер ввода-вывода iкх ьиiaci загipoc в форме IRI' драйверу (в данном
слущас драйверу устройства). который! запускает операцию ввода-вывода.
2. Устройство завершает выполнение операции и генерирует прерыва-
ние. которое обслуживается драйвером.
А. Диспетчер ввода—вывода завершает обработку запроса.
Во втором из представленных примеров программа пользовательского
режима выдает асинхронный запрос. Обработка асинхронного запроса отлича-
ется от обработки синхронного, главным образом, в одном. В случае асипхроп -
ново вызова между шагами 1 и 2 добавляется еще одни, па котором диспетчер
ввода-вывода возвращает управление вызывающей программе. Последняя мо-
жет продолжать выполнять друтис,действия, пока обрабатываются шаги 2 и 5. по
должна синхронизировать свою работу с завершением шага 3, чтобы онреде
WINDOWS NT
лить, когда завершится передача данных. Три стадии обработки как синхрон,
пых, так п асинхронных запросов ввода-вывода подробно описаны в слевк,.
тих разделах.
1 Посылка запроса ввода-вывода
Начнем с простого примера. Пусть приложение синхронно выводит буфер иг.,,
волов на принтер, подключенный к параллельному порту компьютера и упр.щ.
лясмый однослойным драйвером этою порта. (Обычно сначала (Х'уществляец-я
спулинг на диск, но для простоты мы сейчас это игнорируем.)
В Windows NT запрос к принтер) вначале проходил через подсистем) ср.-
ды или DLL, которая, в свою очередь, вызывает сервис NtWritcFile() диспетчера
ввода-вывода. Первый параметр зл ого сервиса — описатель файлового обьекта
определяющий пункт назначения запроса. Так как этим пунктом является парад,
дельный порт, ло подсистема должна была предварительно открыть описал едь
порта (виртуальный файл с именем \pevice\ParallelO) и задать синхронный
ввод-вы вод.
Диспетчер ввода-вывода создает IRP. в котором он сохраняет указатель на
файловый объект и код функции, указывающий драйверу параллельного порта
Рис. 8-9. Посылка и выполнение синхронного запроса.
Глава 8. Система ввода-вывода
тип операции — в данном случае, операция записи. Далее диспетчер ввода -вы-
вода отыскивает драйвер, вызывает его и передаст IKP. На рис. 8—9 показан даль-
нейший путь IRR
Шаги 1—3 на рисунке отвечают посылке синхронного запроса ввода—вы-
вода. Шаг 5, обслуживание прерывания, и шаг 6, завершение обработки запро-
сов, показаны в сокращенном виде для иллюстрации пути прохождения IRP.
Болес подробно они рассмотрены в следующих разделах.
Асинхронный запрос ввода—вывода обрабатывается несколько иначе, как
показано па рис. 8- К).
I IpiniTcp па этом рисунке занят несколькими ожидающими своего выпол-
нения запросами. Новый запрос также должен ждать. Драйвер помещает IRP в
очередь устройства и немедленно возвращает код сехтояння “ввод-вывод вы-
полняется”, который доставляется обратно вызывающей программе. Приложе-
ние (пли подсистема) может продолжать свою работу, пока притер занят.
Вернуть код завершения
"ввод-вывод выполняется"
Пользовательский
режим
Рис. 8-10. Посылка асинхронного запроса.
НОВЫ WINDOWS NT
Например, оно можег готовить другие данные для печати6. Так как ввод-выв^
выполняется асинхронно, поток приложения не должен изменять содержим^
буфера печати, пока принтер нс завершит обработку запроса. Таким обра;,()Л(
прежде чем заполнить буфер другими данными, поток ждет у описателя фай.1;|
который использовался при выдаче запроса ввода—вывода. После завершения
рации ввода—вывода ядро NT устанавливает этот описатель в состояние “cikxxj,
дсп”, и ожидающий полок продолжает работу, возможно, вновь заполняя бу<|ч^р
2.2.2
Обслуживание прерывания
Вторая стадия обработки запроса ввода-вывода, направленного устройству, уц_
равняемому по прерываниям, состоит в обслуживании прерывания устройства
После завершения передачи данных устройство ввода-вывода генерирует ц|х>.
рывание, и в дело вступают драйвер устройст ва, ядро NT и диспетчер ввода-
вывода. На рис. 8—11 показана первая фаза этого процесса (драйвер устройства
представлен более подробно в разд. 8.3.1).
Драйвер устройства
Процедуры
распределения
Запуск
ввода-вывода
Процедура
обслуживания
прерываний
(ISR)
Процедуры
DPC
© ISR перехватывает прерывания
от устройства и помещает DPC в очередь
।
Л
W
к
1
РРСХ-----(DPC
Очередь DPC
Устройство
генерирует
прерывание для
обслуживания
Рис. 8-11. Обслуживание прерывания от устройства (фаза 1).
Сбой питания
Устройство: параллельный порт
Диспетчерский/DPC
АРС
Нормальное выполнение
(?) Диспетчер прерываний
ядра передает
управление процедуре
обслуживания устройство
Таблица
распределения прерываний
Асинхронный .jaii|xx вводя выводя 1«>зв|хпцап управление вызывающей щхмрамыс немедленно-
даже если очередь устройства пуста.
Глава 8. Система ввода-вывода
4
3»
У
fc*
Когда происходит прерывание от устройства, процессор, получивший его ,
передает управление ядру: последнее обращается к своей таблице распределе-
ния прерывании, ч тобы найти процедуру обаумивиния прерываний (interrupt
service routine, ISR) для данного устройства, (Драйверы устройств, генерирую-
щих прерывания, должны предоставлять ISR-процедуру, которая перехватывает
прерывания от устройства и обслуживает запрос прерывания.)
В большинстве ОС прерывания от устройств имеют высокий приоритет,
и (X: обычно блокирует низкоуровневые, а может быть и все, прерывания, пока
ISR нс закончит обслуживание устройства, В Windows NT, однако, 1SR обрабаты-
вает прерывания от устройств в два этапа. Прерывания от устройств имеют вы-
сокий уровень (IRQL), но ISR остается на этом уровне только на время, необхо-
димое для того, чтобы запретить новые прерывания от устройства. Затем по ток
понижает IRQL процессора и завершает обработку прерывания. Эта техника
гарантирует, что программные прерывания п прерывания от устройств па более
низких уровнях нс будут блокированы дольше* необходимого
Драйвер устройства
Процедуры
DPC
Процедуры
распределения
Запуск
ввода-вывода
Процедура
обслуживания
прерываний
(ISR)
(JT) Процедура DPC запускает новый
запрос из очереди принтера, после чего
заканчивает обслуживание принтера
(IRP3)----»(|РР2>,
Очередь устройства t
Сбой питания
Устройство: параллельный порт
и возникает
прерывание DPC
Диспетчерский/DPC
АРС
Нормальное выполнение
(JT) Диспетчер прерываний
передает управление
распределения прерываний
DPC
Очередь DPC
Рис. 8-12. Обслуживание прерывания от устройства (фаза 2)
В зависимости or машинной архитектуры. можетбыть, а может и не быть возможное!!! и|яи рамм-
но коитролирувать, какой процессор фактически получает прерывание.
ОВЫ WINDOWS NT
Для реализации двухшаговой обработки прерываний драйверы устройств
NT используют отложенные вызовы процедур (DPC), описанные в гл. 7. Напри,
мер. когда приходит прерывание от принтера, соответствующая ISR немедленно
запрещает это прерывание. В зависимости от устройства, эт< > может быть сдела-
но простым считыванием его регистра состояния. Затем 1SR сохраняет пнфор.
мацию устройства, которая понадобится в дальнейшем, помещает I )РС в очерсд|,
и завершается. Остаток кода обработки прерывания содержится в DPC.
После завершения ISR ядро N I понижает IRQL процессора до уровня, ц;1
котором тот находился до прерывания. Как указано в гл. 7, помещение DPC h
одну из очередей DPC ядра вызовет программное прерывание, когда IRQL про.
цессора опустится ниже уровня диспстчсрский/DPC. 11а рис. 8— 12 показана вт<>
рая фаза обслуживания прерывания (рис. 8-12 — продолжение рис. 8-11).
Как и другие прерывания, прерывание DPC снова вызывает передачу У п-
равления диспетчеру прерываний ядра. Последний обрабатывает такое преры-
вание, вызывая процедуру DPC драйвера устройства. Процедура DPC принтера
может, помимо прочего, запустить исполнение нового запроса ввода-вывода,
ждущею в очереди принтера, после чего запомнить состояние только что завер-
шившейся операции. Закончив работу, DPC вызывает диспетчер ввода-вывода
для завершения обработки запроса и удаления IRP.
Преимущество использования DPC для выполнения большей части работы
по обслуживанию устройства состоит в том, что все блокированные прерыва-
ния, чей приоритет лежит между IRQL устройства и диспетчерским/DPC, снова
разрешаются, прежде чем произойдет более низкоприоритетное прерывание
DPC. Таким образом, прерывания промежуточных уровней обслуживаются бо-
лее оперативно.
Завершение обработки запроса
После завершения выполнения процедуры DPC драйвера устройства остается
проделать еще некоторую работу, прежде чем запрос ввода-вывода завершится.
Третий этап обработки называется завершенней ввода-вывода (I/O completion),
и связанные с ним действия зависят от типа выполняемого запроса. Например,
все сервисы ввода—вывода записывают результат операции в б.чок состояния
ввода—вывода (I/O status block) — структуру данных, предоставляемую вызыва-
ющей программой. Аналогично, некоторые сервисы, выполняющие буферизо-
ванный ввод—вывод, требуют, чтобы система ввода—вывода возвратила данные
вызывающему потоку.
В обоих случаях подсистема ввода-вывода должна скопировать некото-
рые данные из системной памяти в виртуальное адресное пространство вызыва-
ющею процесса. Для получения доступа к этому7 адресному пространству дис-
петчер ввода-вывода должен пересылать данные “в кемггсксте вызывающей > по-
тока”, т. с. во время исполнения этою потока. ?>го достигается путем посььчкп
данному потоку АРС режима ядра, как показано па рис. 8-13 (этот рисунок '
продолжение рис. 8-12).
АРС в определенной степени напоминает 1)14’, за исключением тою, что
первый должен выполняться в контексте определенною потока, а второй - |!
контексте любого. Более того, и АРС, и 1)РС вызывайте программное прерывание’-
но прерывание АРС имеет более низкий уровень.
Системный код (такой, как диспетчер ввода—вывода) посылает АРС’ режтг
ма ядра заданному потоку, вызывая процедуру ядра. Когда поток снова начнет’
I лова . система ввода-вывода
Диспетчер ввода-вывода
Диспетчер ввода-вывода генерирует
АРС для завершения ввода-вывода
7 ) Процедура DPC вызывает диспетчер
ввода-вывода для завершения
в контексте вызывающего потока
выполнения запроса
Очередь АРС потока
Рис. 8-13. Завершение запроса ввода-вывода (фаза 1).
Т<Р
исполняться на низком IRQL, возникнет программное прерывание. Рис. 8—14 (про-
должение рис. 8-13) иллюстрирует вторую стадию завершения ввода-вывода.
При возникновении прерывания АРС ядро передает управление процеду-
ре АРС диспетчера ввода-вывода, кот орая копирует данные (если это необходи-
мо) и код завершения в адресное пространство вызывающего процесса, удаляет
IRP данною запроса и устанавливает описатель файла (или событие вызываю-
щей программы, см. ниже) в состояние "свободен”. Ввод-вывод завершен. Вызы-
вающий поток или любые другие потоки, ждущие у описат еля файла (в данном
примере у описателя параллельною порта), выходят из состояния ожидания и
возобновляют работу.
И последнее замечание о завершении ввода-вывода. Асинхронные серви-
сы ввода—вывода позволяют передавать им в качестве параметра АРС пользова-
тельского режима. Если вызывающая программа сделает это, диспетчер в конце
обработки завершения ввода-вывода направит ей этот АРС Данное средство
позволяет вызывающей программе заранее указать дейст вия, которые она жела-
ет выполнить по завершении запроса ввода-вывода. Например, поток подсисте-
мы среды может выполнять операцию чтения для клиентского потока. Поток
подсистемы выдаст- асинхронный запрос на чтение файла и указывает процеду-
ру АРС пол1>зовательского режима. После этого он может выполнять обслужива-
ние других клиентских запросов. По завершении ввода—вывода диспетчер на-
правляет- данный АРС обратно потоку подсистемы, что вызывает прерывание
последнего. Таким образом инициируется выполнение процедуры АРС подсис-
темой, которая в данном примере возвращает клиенту результаты операции чте-
ния. Затем ядро NT восстанавливает контекст потока подсистемы, и он продол-
жает исполняться стогоже места, где было получено прерывание ЛИ:. (Для про-
граммистов Win32 АРС пользовательского режима представлены как “процеду-
ры завершения” в API ReadFileExQ и WriteFilcExQ.)
Ы WINDOWS NT
1
I
ельский
L,
Подсистемы
среды
или DLL
Р°
(тГ) Процедура АРС режима
Диспетчер
ввода-вывода
ядра записывает данные
в адресное пространство
потока, устанавливает
описатель файла в
состояние “свободен",
устанавливает в очередь
на исполнение АРС
пользовательского
режима (если нужно)
и удаляет IRP
(l6) Диспетчер прерываний
передает управление
процедуре АРС
диспетчера
ввода-вывода
ь АРС потока
Таблица
распределения прерываний
Рис. 8-14. Завершение запроса ввода-вывода (фаза 2).
Запросы ввода-вывода к многослойным драйверам
В предыдущем примере рассматривались запросы ввода-вывода к простому ус-
тройству, управляемому одним драйвером. Обработка ввода-вывода для файло-
вых устройств и запросов к другим многослойным драйверам во многом сходна.
Основное отличие, конечно, в том, что к модели добавляется еще один или не-
сколько уровней обработки. На рис. 8-15 показано прохождение асинхронного
запроса через несколько слоев драйверов. Здесь рассматривается пример диска,
управляемого файловой системой.
Как обычно, диспетчер ввода-вывода получает запрос и создает для его
представления пакет запроса ввода-вывода. На этот раз, однако, он передаст
пакет драйверу файловой системы. В этот момент драйвер файловой системы в
основном и управляет выполнением запроса. В зависимости от типа запроса,
файловая система может либо послать драйверу устройства тот же самый IRP-
либо сгенерировать несколько дополнительных пакетов и направить их драйве-
ру по отдельности.
Вероятнее всею, файловая система будет повторно использовать оригиналь-
ный IRP, если полученный запрос можно преобразовать в один непосредствен-
ный запрос к устройству Например, если приложение выдает запрос на чтение
Iлево 8. Система ввода-вывода
первых 512 байт файла на гибком диске, то файловая система FAT просто вызове т
драйвер диска, запрашивая чт ение одного сектора диска с мес та начала файла.
Для поддержки использования пакета несколькими драйверами, располо-
женными друг над друг-ом, IRP содержит- набор областей стека IRP (IRP stack
locations), с.м. рис. 8—15. Эти области данных, но одной для каждого вызываемого
драйвера, содержат информацию, необходимую ему для обработки своей части
запроса — например, код функции, параметры и информацию контекста драй-
вера. Как показано на рис. 8— 15, дополнительные области стека заполняются по
мере передачи IRP от одного драйвера другому. IRP можно рассматривать как
стек в смысле механизма добавления и удаления данных. Однако IRP не связан
ни с каким процессом, и ст о размер не может увеличиваться или сокращаться. В
ввода-вывода
Сервисы
Подсистемы
среды
или DLL
Вернуть код завершения
"ввод-вывод выполняется"
Пользовательский
режим
Режим ядра
Создать IRP, заполнить его
первую область стека и вызвать
драйвер файловой системы
Диспетчер
ввода-вывода
Драйвер
файловой
системы
Вернуть код завершения
"ввод-вывод выполняется"
текущий
(F) Вернуть код завершения
"ввод-вывод выполняется'
Послать данные IRP на устройство
(или поставить IRP в очередь)
и вызвать управление
диска
Рис. 8-15. Посылка асинхронного запроса многослойному драйверу.
СНОВЫ WINDOWS NT
Сервисы
Диспетчер
ввода-вывода
Подсистемы
среды
или DLL
(и) В процессе завершения ввода-вывода
результаты помещаются в адресное
пространство вызывающей программы
Пользовательский
режим
Режим ядра
HrF)
Драйвер
файловой
системы
^6) Драйвер файловой системы
выполняет необходимую очистку
текущий
IRP
Драйвер
диска
(V) Драйвер диска обслуживает прерывание,
после чего посылает для завершения
ввода-вывода DPC, которая извлекает
текущий вторую область стека из IRP и вызывает
драйвер файловой системы
Рис. 8-16. Завершение многослойного запроса ввода-вывода.
начале операции ввода-вывода диспетчер ввода-вывода размещает IRP в рези-
дентной части системной памяти.
После того, как дисковый драйвер завершит передачу данных, диск гене-
рирует прерывание, и ввод-вывод завершается, как показано на рис. 8-16 (это1
рисунок — продолжение рис. 8-15).
Вместо повторного использования одного IRP файловая система может с< >з-
дать ipynny ассиции])ов(11П1ЫХ J1<P (associated IRPs), которые будут работать над
одним запросом параллельно. Например, если считываемые из файла данные
разбросаны по разным местам диска, то драйвер файловой системы может со-
здать несколько IRP, каждый из которых считывает порцию данных из своей3
сектора. Этот случай иллюстрируется рис. 8-17.
Драйвер файловой системы передает ассоциированные IRP драйверу дис-
ка, который ставит их в очередь устройства. Они обрабатываются по одному, '
Глава 8. Система ввода-вывода
Рис. 8-17. Посылка ассоциированных IRP.
драйвер файловой системы отслеживает возвращаемые данные. Когда заверше-
но выполнение всех ассоциированных IRP, система ввода-вывода завершает ис-
ходный IRP и возвращает управление вызывающей программе, как показано па
рис. 8-18 (это продолжение рис. 8-17).
ОСНОВЫ WINDOWS NT
После завершения всех ассоциированных
IRP завершается первоначальный IRP,
возвращая вызывающей программе
код завершения или данные „
Пользовательские)
режим
Bf
Рис. 8-18. Завершение ассоциированных IRR
8.2.4 Особенности использования асинхронного ввода-вывода
При вызове сервисов ввода—вывода NT разработчик должен определить, вызы-
вать ли их синхронно или асинхронно. Для операций, которые выполняются
быстро или в течение предсказуемого времени, эффективен синхронный ввоД"
вывод, поэтому для таких сервисов система ввода-вывода предоставляет только
синхронный режим работы. Асинхронный ввод—вывод даст наибольшие прО'
имущества тогда, когда время выполнения операции велико или очень непосто-
янно. Например, количество файлов в каталоге может существенно повлиять
время их перечисления. Поэтому сервис опроса каталога файлов является, п°
умолчанию, асинхронным — также, как и чтение файла, запись в файл, уведоМ'
ление об изменении содержимого каталога и некоторые другие сервисы.
Асинхронный ввод—вывод требует несколько большего объема програ^'
мирования в обмен на более тонкий контроль операций ввода—вывода и п<>'
Глава 8. Система ввода-вывода
тенциалыюе повышение производительности. Поток, использующий асинхрон-
ный ввод-вывод, не задерживается на время пересылки данных. Однако он
должен синхронизировать использование передаваемых данных с моментом
завершения передачи устройством.
Выполняя асинхронный ввод—вывод, код пользовательского режима мо-
жет использовать для такой синхронизации один из нескольких объектов ис-
полнительной системы. Файловые объекты поддерживают синхронизацию, так
что самым простым способом является ожидание у описателя файла в некото-
рой точке после выдачи запроса ввода—вывода. Когда передача данных законче-
на, диспетчер ввода—вывода устанавливает описатель файла в состояние “свобо-
ден”, и выполнение ожидающего потока возобновляется.
Рис. 8—19 иллюстрирует проблему, которая может возникнуть при исполь-
зовании этого метода, если для вызывающей программы параллельно выполня-
ются несколько запросов ввода-вывода. Предположим, что сервер базы данных,
выполняющийся под NT, получае т клиентский запрос на чтение записи из базы.
Пока эта операция выполняется, чтение записи из базы запрашивается другим
клиентским потоком. Сервер, который открыл файл базы данных только один
раз, использует для ссылки на него единственный описатель.
Два патока выдают запросы к файлу с использованием одного и того же опи-
сателя, после чего оба вдут у данного описателя. Пусть, как показано на рис. 8-19,
Серверный
поток 1
Серверный
поток 2
Диспетчер
ввода-вывода
Устройство
земя
буфер1 =
геаО(описатель_файла,
запись_3)
у/аИ(ог1исательфайла)
сПоток 1 ждет> буфер2 =
геа9(описатель_файла.
запись12)
\л/а11(описатель_файла)
<Поток 2 ждет>
Выполнить
пересылку
в буфер 1
Завершить ввод-вывод
для буфера 1
Установить описатель
файла в состояние
"свободен"
«Ожидание окончено>
Возвратить данные
в буфер 1
сОжидание окончено
Возвратить данные
в буфер 2
Выполнить
пересылку
в буфер 2
Рис. 8-19. Ошибочное использование описателя файла.
ОСНОВЫ WINDOWS NT
одна из oiiepai (ий ввода—вывода завершается. Когда это происходит, диспетчер ввщ
да-вывода устанавливает описатель файла в состояние “свободен”, что освобожу,
ет из состояния ожидания оба потока, п они продолжают свое выполнение.
К сожалению, поскольку порядок исполнения потоков меняется и, кромс
того, поток в любое время может быт ь вытеснен другим потоком, невозможно
определить, какая именно из двух операций завершилась. Асинхронные запрос Ь1
ввода-вывода не обязательно завершаются в порядке их выдачи. В примере ца
рис. 8-19 завершилась только одна передача данных, поданные клиентам возвра.
щают оба потока. Следовательно, один из клиентов получит неверные результат ц
Для решения данной проблемы можно посоветовать избегать синхрониза-
ции с использованием описателя файла, когда этот описатель используется ддя
выдачи запросов несколькими потоками. Вместо этого, каждый поток может
ждат ь на отдельном объекте—событии исполнительной системы, используя ев,
для каждого запроса ввода-вывода. Для этой цели всем асинхронным сервисам
ввода-вывода NT можно передавать описатель объекта-события. В качестве
альтернативы вызывающая программа может задать ЛРС, который будет испол-
нять некоторую функцию после завершения обработки запроса ввода—вывода
(например, функцию, возвращающую данные клиент}’).
Другое решение — задать синхронное выполнение всех сервисов ввода-
вывода (чтобы гарантировать выполнение в любой момент' времени не более
одного ввода-вывода). Когда диспетчер выполняет синхронный ввод—вывод, он
также упорядочивает множественные запросы ввода-вывода. Иными словами,
если два потока запрашивают ввод-вывод с использованием одного и того же
описателя файла, то диспетчер ввода-вывода гарантирует приостановку второ-
го потока до тех пор, пока нс завершится операция ввода—вывода первого. (Эта
возможность широко используется подсистемой OS/2, которая всегда упорядо-
чивает множественные запросы ввода-вывода.)
8.3 Послойная модель драйвера
Предыдущие разделы были посвящены в основном архитектуре системы ввода-
вывода и передаче запроса ввода—вывода в процессе его обработки. В этом раз-
деле будет описана структура драйверов, взаимосвязь между ними и диспетче-
ром ввода-вывода, а также способы взаимодействия между драйверами в по-
слойной модели. В конце раздела обсуждаются две важные особенности систе-
мы, оказывающие влияние на драйверы и их разработку.
8.3.1 Структура драйвера
Дисковод гибких дисков, жесткий диск, подключенный к шине SCSI, графичес-
кий дисплей, файловая система FAT и сетевая плата — это радикально отличаю-
щиеся друг от-друга “устройства", ио для диспетчера ввода-вывода между ним11
практически нет разницы. Каждый драйвер NT содержит следующий стандарт-
ный набор компонентов (или его часть):
Процедура инициализации. Диспетчер ввода-вывода исполняет ее пр"
загрузке драйвера в ОС. Данная процедура создает системные объекты-
используемые диспетчером для распознавания драйвера и доступа к i icM)
Глава 8. истема ввода-вывода
• Набор процедур распределения. Процедуры распределения — это
главные функции, предоставляемые драйверами устройств. Примера-
ми служат функции чтения, записи и другие, поддерживаемые устрой
ством, файловой системой или сетью. Когда диспетчер ввода-вывода
получает запрос на выполнение некоторой операции, он генерирует
IRP и обращается к драйверу через одну из процедур распределения
последнего.
• Процедура запуска ввода—вывода. Драйвер использует эту npoi (едуру для
начала передачи данных на устройство или от него.
1SR. Диспетчер прерываний ядра пс|эедает управление этой процедуре
при получении прерывания от устройства. В модели ввода—вывода NT
процедуры обслужнвашы прерываний выполняются на высоком IRQL и
поэтому должны выполнять как можно меныиий объем работы, чтобы
избежать излишне долгого блокирования низкоуровневых прерываний.
Для выполнения оставшейся части обработки прерывания LSR генери-
рует DPC, который выполняется при меньшем IRQL (Обратите внима-
ния, что ISR сеть только у драйверов устройств, генерирующих преры-
вания. У файловой системы, например, се нет.)
.£ Процедура БРСдля обслуживания прерывания. После выполнения ISR
эта процедура выполняет большую часть работы по обслуживанию пре-
рывания. Она исполняется на более низком IRQL, чем ISR, чтобы избе-
жать ненужного блокирования других прерываний. Процедура DPC ини-
циирует завершение ввода—вывода и запускает следующий запрос из
очереди на обработку' устройством.
Процедура завершения. Драйвер верхнего уровня может определить
процедуру завершения, вызов которой будет уведомлять его о заверше-
нии обработ ки IRP драйвером нижнего уровня. Например, диспетчер
ввода—вывода вызывает процедуру завершения файловой системы пос-
ле того, как драйвер устройства закончит выполнение чтения или запи-
си файла. Процедура завершения информирует файловую систему об
успешном окончании, сбое или отмене операции и позволяет послед-
ней выполнить необходимую очистку.
• Процедура отмены ввода—вывода. Если имеется возможность отмены
операции ввода-вывода, то драйвер может определить одну или не-
сколько процедур oi-мены. Используемая процедура может изменяться
в зависимости от того, насколько далеко продвинулось выполнение
операции ввода-вывода. Информация о процедуре- отмены, активной в
данный момент времени, хранится в IRP.
Процедура вьпрузки. Эта процедура освобождает системные ресурсы,
которыми пользовался драйвер, чтобы диспетчер ввода—вывода мог
удалить его из памя ти. Драйвер может загружаться и вьиру жаться в про-
цессе работы системы.
Процедуры протоксшированпя ошибок. Когда возникает неожиданная
ошибка (например, при сбое- на диске), процеду ра протоколирования
ошибок отмечает этот факт и уведомляет о нем диспетчер ввода—выво-
да. который записывает соответствующую информацию в файл журна-
ла ошибок.
СНОВЫ WINDOWS NT
Простейший драйвер включает процедуру инициализации, загружающую
его в систему, и процедуру вьпрузкн, удаляющую сто. Отi также содержит по одпог,
процедуре распределения для каждой поддерживаемой им операции (или одщ.
процедуру распределения, обрабатывающую нее операции). Драйверы устройств
управляемых по прерываниям, кроме того, содержал необязательную процедуру
запуска ввода-вывода; процедуру обработки прерываний, перехватывающую
прерывание от устройства; процедуру DPC, выполняющую обработку прерыщ.
ния, которая не требует высокого IRQL. Кроме того, у многослойного драйвера
верхнего уровня обычно имеется процедура завершения.
.3.2 Объект-драйвер и объект-устройство
К<>|да поток открывает описатель файлового объекта, диспетчер ввода-вывода дол-
жен по имени этого объекта определить, к какому драйверу (или драйверами он
должен обратиться для обработки запроса. Болес того, диспетчер ввода-вывода
должен иметь возможность найти эту информацию при последующем использова-
нии описателя потоком. Для этой цели предназначены следующие объекты:
• Объект—драйвер (driver object), представляющий в системе некоторый
драйвер и хранящий для диспетчера ввода-вывода адреса всех щюце-
дур распределения драйвера (точек входа).
Объект—устройство (device object), представляющий физическое,. ю-
гичсское или виртуальное устройство, имеющееся в системе, и описы-
вающий его характеристики, такие как требования по выравниванию
буферов и местоположение очереди устройства для хранения поступа-
ющих пакетов запросов ввода—вывода.
Объект—драйвер создается диспетчером ввода—вывода при загрузке драп-
вера в систему; после чего диспетчер вызывает процедуру инициализации драй-
Устройства,
угравляемь1®
данным
драйверов
Рис. 8-20. Объект-драйвер.
Глава 8. Система ввода-вывода
вера, которая заполняет объект точками входа драйвера. Кроме того, процедура
hi нтциализа! ути создает по од! юму объекту-устройству для каждого устройства,
управляемого данным драйвером. Она связывает объекты-устройства с объек-
том-драйвером, как показано на рис. 8—20.
Как отмечалось в гл. 3, при от крытии описателя файлового объекта вы-
зывающая прелрамма передает имя файла. Частью этого имени является имя
объекта-устройства, на котором находится файл. Например, имя \DeviceO\Flop-
l>y()\myfile.dat обозначает файл myjilerial, расположенный на гибком диске, уста-
новленном в дисковод А. Подстрока \Derice()\FloppyO является именем объекта-
устройства, представляющего этот дисковод. При откры тии myfiledat диспетчер
ввода-вывода создает файловый объект, сохраняет в нем указатель па объект-
устройство ПорруО, после чего возвращает описатель вызывающей программе.
Затем, при использовании вызывающей прсяраммой этого описателя, диспет-
чер ввода-вывода сможет сразу же найти объект—устройство FloppyO.
Из рис. 8-20 видно, что объект—устройство содержит- обратный указатель
на объект—драйвер, благодаря чему диспетчер ввода—вывода может определить,
процедуру- какого драйвера он должен вызват ь при получении запроса. Он ис-
пользует объект—устройство, чтобы найти объект-драйвер, представляющий
драйвер, который обслуокиваст эго устройство. Затем он использует код функ-
ции в качестве индекса внутри объекта-драйвера (каждый код функции соот-
ветствует некоторой точке входа драйвера).
Часто с объектом—драйвером связано несколько объектов-устройств.
Список объектов—устройств представляет физические, лопические и виртуаль-
ные устройства, управляемые драйвером. Например, каждому разделу жесткого
диска соответствует отдельный объект-устройство, содержащий информацию
об этом разделе. Однако для всех разделов используется один драйвер жесткого
диска. При выгрузке драйвера из системы диспетчер ввода-вывода использует
данный список объектов—устройств, чтобы определить, па какие устройства
повлияет удаление драйвера.
Использование объектов для хранения информации о драйверах избавля-
ет диспетчер ввода-вывода от необходимости знать детали отдельных драйве-
ров. Чтобы найти драйвер, диспетчер ввода-вывода просто переходит по указа-
телю — эго обеспечивает поддержку- переносимости и позволяет легко добав-
лять новые драйверы. Представление устройств и драйвс|х>в разными объекта-
ми также позволяет системе ввода-вывода легко назначать драйверам дополни-
тельные устройства при изменении конфигурации.
'3.3 Пакет запроса ввода-вывода
В IRP система ввода-вывода сохраняет информацию, которая необходима ей
для обработки запроса ввода—вывода. Когда поток вызывает сервис ввода-выво-
да, диспетчер ввода—вывода создаст' IRP, представляющий данную операцию в
течение всего времени ее выполнения. В IRP диспетчер сохраняет указатель па
файловый объект, заданный вызывающей пршраммой. На рис. 8—21 показана
взаимосвязь между IRI’ и объектами системы ввода—вывода.
IRP состоит из двух частей: фиксированной части (называемой заголов-
ком) н одной пли нескольких областей стека. В фиксированной части указыва-
ется тип и размер зан|юса; вид запроса - синхронный или асинхронный; указа-
тель на буфер для буферизованного ввода-вывода; информация состояния,
UC ОВЫ WINDOWS NT
изменяющаяся в процессе обработки запроса. Область стека IRP содержит ко ,
функции, параметры, специфичные для этой функции и указатель на файли.
вын объект вызывающей программы. Па рис. 8-21 область ст ека содержи! код
функции ЗАПИСЬ.
В процессе своей обработки IRP хранится в очереди IRR связанной с пото-
ком, запросившим ввод—вывод. Это позволяет системе ввода-вывода найти ц
удалите IRP, ожидающие обработки, если поток завершился или был заверпк-н
8.3.4 Функционирование многослойных драйверов
На рис. 8-21 изображен вызов диспетчером ввода-вывода однослойного
драйвера устройства. Диспетчер использует переданный ему' при вызове опи-
сатель файла, чтобы найти объект-устройство и объект—драйвер, и затем вы-
зывает драйвер. Однако большинство операций ввода-вывода не столь иро-
на принтер, передавая
описатель файлового объекта
Пользовательский
режим
Режим ядра
Сервисы
Диспетчер
ввода-вывода
Диспетчер ввода-вывода
создает IRP и инициализирует
первую область стека ,,
^Заголовок 1RP,
Область
стека IRP
ЗАПИСЬ
Параметры
Объект-
устройство
Используя объект-драйвер,
диспетчер ввода-вывода
находит процедуру
распределения ЗАПИСЬ
и вызывает ее, передовая IRP
Процедуры
распределения
Запуск
ввода-вывода
Процедура
обслуживания
прерываний
(ISR)
Процедуры
DPC
Драйвер устройства
Рис. 8-21. Вызов драйвера.
Глава 8. Система ввода-вывода
сты. Обычно для обработки запроса ввода-вывода необходимо вызвать более
одного драйвера.
Архитектура системы ввода—вывода позволяет драйверам располагаться
слоями друг над другом; один драйвер может выполнят ь некоторое действие на
основе информации, хранящейся в первой области стека IRI’ после чего пере-
дать запрос другому драйверу, помещая необходимую тому Н1к|юр>мацню во вто-
рую область стека. Например, запись данных на жесткий диск требует участия
минимум двух драйверов, как показано на рис. 8-22.
11а этом рисунке показано “разделение груда” между двумя расположенны-
ми послойно драйверами. Диспетчер ввода—вывода получает запрос на запись
по смещению от начала файла. Этот запрос передается диспетчером драйверу
файловой системы, который преобразует параметры файловой операции в на-
чальный сектор на диске и смещение от границы сектора. Драйвер файловой
системы обращает ся к диспет черу ввода-вывода для передачи запроса драйверу
диска, который транслирует параметры запроса в физический адрес на диске н
выполняет пересылку данных.
Подсистемы
среды
, или DLL .
Пользовательский
режим
(Г) NtWriteFile (описатель_файла. буфер, данных)
Режим ядра
Системные сервисы
Драйвер файловой
системы
Записать данные по
'—' заданному смещению в файле
Диспетчер
ввода-вывода
©Транслировать смещение от начала
файла в смещение на диске и вызвать
следующий драйвер (через диспетчер
ввода-вывода)
I
Драйвер диска
©Вызвать драйвер для записи
данных по смещению от начала диска
©Транслировать смещение на диске С-
в физический адрес и переслать данные
Рис. 8-22. Расположенные слоями драйверы файловой системы и диска
Так как вес драйверы — и драйверы устройств, и драйверы файловых сцс,
тем — предоставляют ОС одинаковый интерфейс, в их иерархию легко добавить
новый драйвер, нс затрагивая другие драйверы или систему ввода-вывода. Ца,
пример, можно добавить драйвер, который будет представлять несколько дне.
ков в виде одного очень большого диска. Такой драйвер действительно суще,
ствуег в Window's NT для поддержки отказоустойчивых дисков. Этот драйвер д(ь
гического многотомного “устройства” располагается между файловой системой
и драйверами дисков, как показано на рис. 8—23.
Обратите внимание, что добавление в данном примере нового драйвера
в иерархию не повлияло ни на драйвер файловой системы, пи на драйвер
диска. Они работают’ так же, как и до этого. Для определения набора и порядка
вызова драйверов для доступа к устройству диспетчер ввода-вывода использу-
ет внутренние структуры данных, создаваемые при загрузке и последующем
монтировании драйвера.
8.3.5 Вопросы разработки драйверов
Две особенности Windows NT — мультипроцессорная обработка и восстановле-
ние после сбоя питания — требуют некоторого дополнительного внимания при
создании драйвера. В многопроцессорной среде прерывание может возникнуть
на любом из процессоров во время обслуживания прерывания того же типа на
другом процессоре, что вызывает одновременное выполнение драйвера на двух
процессорах. Такая среда заставляет драйвер использовать модель функционир >-
ваиия, отличную от моделей, используемых, к примеру, в ОС MS-DOS и OS/2.
Windows NT также предоставляет возможность восстановления после ава-
рии питания. Большинство ОС терпят крах, если во время их работы происходит
сбой питания. При этом теряется информация операций ввода—вывода, выпол-
нявшихся в момент сбоя. В противоположность этому; если система Windows NT
оборудована источникам бесперебойного питания (uninterruptible power supply.
UPS), она заблаговременно уведомляет пользователей об угрозе отказа питания,
после чего выполняет управляемый останов. Если komi шютер оборудован резерв-
ными батареями для памяти, то Windows NT предоставляет возможность “теп-
лой перезагрузки”, что позволяет системе ввода—вывода возобновить операции
ввода-вывода, выполнявшиеся в момент сбоя4. В данном разделе описываются
некоторые соображения по разработке драйверов, связанные с мультипроцес-
сорной обработкой и возможностями восстановления после сбоя питания.
8.3.5.1 Мультипроцессорная обработка
В симметричной мультипроцессорной среде один и тот же системный ко/t Ml)'
жег выполнятся на нескольких процессорах одновременно. Хотя и при разра-
ботке всей системы в целом должно быть обеспечено ее правильное функцио-
нирование па многопроцессорных компьютерах, вопросы, связанные с мульти-
процессорной обработкой, нигде не остры т ак, как в системе ввода—вывода, осо
бепно при разработке драйверов уст ройств.
Основное требование, предъявляемое к коду для многопроцессорной сре-
ды, — предотвращать совместное использование ресурса двумя потоками одпо-
СТакая возможность можст «ясттствокать в к.|мюГ| версии системы.
Глава 8. Система ввода-вывода
Подсистемы
среды
. или DLL .
Пользовательский
режим
Режим ядро
(Г) NtWriteFile (описатель_файла, буфер„данных)
Системные сервисы
Записать данные по
7 заданному смещению в файле
Драйвер
файловой
системы
Драйвер
диска
Диспетчер
ввода-вывода
Драйвер
многотомного
диска
©Транслировать смещение от
начала файла в смещение
но диске и вызвать следующий
драйвер (через диспетчер
ввода-вывода)
©Вызвать драйвер для записи
данных по смещению от
начала диска
©Транслировать смещение от
начала диска в номер диска
и смещение и вызвать
следующий драйвер (через
диспетчер ввода-вывода)
1
2
©Вызвать следующий драйвер
для записи данных на диск 3 по
смещению относительного
начала этого диска
Транслировать смещение на диске в физический
адрес на диске 3 и переслать данные
I-FT1
' 3
Рис. 8-23. Добавление драйвера.
временно. Как и другие компоненты системы, драйвер может выполняться одщ,.
временно на двух процессорах и, следовательно, должен синхронизировать д()
ступ к своим данным при помощи п|х.-достакляемой ядром спин—блокировки. |<
системе ввода-вывода к совместно используемым ресурсам относятся иетолы^
структуры данных драйверов, но также и однопользовательские устройства
Например, если два потока пытаются одновременно выводить па принтер, щ
данные не должны перемешиваться.
Особой заботы в системе ввода-вывода требует корректная обработка
прерываний на многопроцессорной машине. Большая часть кода драйверов ис.
полнястся на том же IRQL, который был установлен в момент запуска операции
ввода-вывода вызывающей программой. Для нормальных потоков пользова-
тельского режима это будет самый низкий IRQL. С другой стороны, прерывания
устройств имеют более высокий приоритет. Таким образом, устройство может
сгенерировать прерывание и вызвать выполни me LSR во время исполнения кода
его собственного драйвера. Если драйвер устройства изменял данные, которые
изменяет и ISR (например, регистры устройств, область динамически распреде-
ляемой памяти или статические данные), то во время выполнения ISR эти дан-
ные могут быть разрушены. Иллюстрацией служит рис. 8—24.
Этот сценарий возможен нс только на многопроцессорных системах. Раз-
новидность данной проблемы может возникнуть и на однопроцессорной .маши-
не Для борьбы с нею драйверы устройств в OS/2 и MS-DOS, например, обычно
запрещают прерывания (при помощи команды C1.I на процессорах Intel х8б) па
время работы с регистрами устройств или другими данными, используемыми
совместно с ISR. Блокирование прерываний позволяет драйверу устройства
исключить возможность вмешательства в его работу и повреждения данных со
стороны 1SR.
Данная стратегия эффективна на однопроцессорных машинах. Однако и
многопроцессорной системе отключение прерываний на одном процессоре не
исключает’ возникновения и обслуживания прерывания па другом. Например,
предположим, что поток, выполняющийся на процессоре 1. отключает прерыва-
ния и начинает’ вводить данные в пархтлетьпый порт. Пока он записывает дан-
ные в буфер порта, принтер, подключенный к порту, генерирует прерывание.
Рис. 8-24. Повреждение данных в драйвере устройства.
Процессор 2, прерывания на кото^хчм не отключены, принимает его и начинает
исполнение ISR для параллельного порча. Эта ISR записывает данные в буфер
порта. Теперь состояние буфера нс определено.
Чтобы избежать подобной ситуации, драйвер устройства для NT должен
синхронизировать свой доступ к любым данным, которые совместно использу-
ются им и ISR. Прежде чем пчятатъея обновлять такие данные, драйвер устроч*ч-
ства должен заблокпроччать достучч к ним всем остальным потокам, чтобы пре-
дотвратить одновременное изменение* даччччых. Более того, используемая им бло-
кировка должна находиться в памяти, члобальиоч-ч для всех процессоров. Ядро
NT предоставляет специальные чцхщедуры, которые должны вызчлваться драй-
верами при обращеничч к данным, доступным также и их ISR. Синхронччзацччон-
ные процедуры ядра исклчочачот выполненчче 1SR чча то время, пока идет работ а
с этими совместно используемыми данными.
Из сказанного вьчччче ясно, что, хотя ISR требуют особого внимания, любые
данные, используемые драйвером устройства, мочут бьчтч, объектом доступа т ого
же драйвера, вычюлччячочцсчося на другом процессоре. Таким образом, синхро-
низация использования глобальнчях или совместно используемых даччччых со-
ччершенччо необходима для драйвера. Если эти данные ччеч чользуются 1SR, то драй-
вер должечч задействовать ччроцедуры епччхрочпчзацичч ядра: в противччом случае
драйвер может иеччользовать спин-блокировку ядра.
8.3.5.2 Восстановление после сбоя питания
При возникччовении аварии питаччия (даже если она будет ликвидирована тач< быс-
тро, ччо человек се нс заметит) элечечрочччччяе компоненты и, в частности, устрой-
ства ччвода-выччода, вероятно. “почувствучот”перебой напряжения. Данные, храня-
ччцчеся в регистре устройства, ч чач чример. мочут быть повреждены, а само устрой -
егво — чча мгновение выключиться и перейти чч ччеопрсдсленное состояние.
Тач< как драйверы устройств выполняются в режиме ядра с доступом к си-
стемной памяти, ечтой питания. оказывающий влияние чча работу устройства,
может вызвать ссрьезччьче ччрочэлсмьч в работе ОС. Для ччредотврачч1енччя подоб-
иях проблем чечждчяй драйвер устройства в Windows NT должечч знать о том, что
произошел сбой питания, хехчя бы и кратковрсменччый, и устанавливать свое
устройство в некоторое определенное состояние после сбоя. Кроме того, каждая
прерванная операция ввода-вывода должна бьчтч> ччерезапучцечча; если это нс воз
можччо. то. что крайней мере, диспетчер ввода вывода должечч бьчтч. уведомлен о
сбое, чтобы очч моч’ вернуть ччызыччачочцечт ччрочраммс код очччибкчч.
Диспетчер ввода-вывода совместно с ядром NT предоставляет драйверам
устройств возможность коррсчстччо обрабатывать прерьчваччччя сбоя пччтаччччя. Прчч
аварии пччтания генерируется прерывание сбоя чтитачпчя, чч у ОС есть ччечюлыччеич
промежуток времени для подчотовкчч к чттклчоченчччо напряжения. Ядро быстро
копирует' в память все важные еччеге.мные регистры, включая указатель команды.
Если память компьютера снабжена резервньчмчч батареями, то эта информацччя чче
теряется, чч когда ччччтание будет восстаччочечеччо, ядро и система ввода—выччода чче-
пользучот се для ччозобноччлеччччя ччеччолч ченччя с места сбоя. Система вводавывода
может ччерсзаччустить или отмеччччтъ выполчченис прерванных оччерацип.
Каждычч драйвер устройства в NT может выполнить ччссколько действий,
чтобы очх'чегчччть ччосстаноччлсччпс ччослс сбоя пччтаччччя. Во-первых, очч можеточч-
ределччть чч зарегистрировать прочдедуру воссчаччовлеччия питанччя, которая будет
сбрасъчвать устройство в задаччччое состояние после сбоя пччтаччччя. Когда подача
напряжения будет восстановлена, ядро отыщет и исполнит процедуру вос<та,
новления питания каждого драйвера.
Во-вторых, каждый драйвер гарантирует невозможность возникноггсщ^
прерывания сбоя питания в момент записи им критических данных на устрой
ство. Эта важно, потому что после восстановления питания процессор возобц,,.
вит свою работу по состоянию указателя команд на момент сбоя. Любая опера.
цня, выполнявшаяся на устройстве в момент сбоя, может быть, а может и нс бьП)
завершена корректно, и ее нужно выполнить снова. Прежде чем записывав
критическую информацию в аппаратные регистры, каждый драйвер снача.ъ
проверяет, не произошел ли уже сбой питания, после чего кратковременно зац,
рещает прерывание сбоя питания, поднимая IRQL процессора до уровня -по,
прерывания. После записи данных каждый драйвер немедленно понижает IR(w
(точнее, восстанавливает’ предыдущий IRQL). Если в процессе записи происхо-
дит сбой питания, то прерывание на время откладывается, пока выполнение
критической операции не завершится. Таким образом, гарантируется, что п< х. |С
перезапуска системы драйвер нс окажется в середине критической операции
ошибочно предполагая, что предыдущий важный шаг был успешно выполнен.
8.4 Заключение
Система ввода—вывода NT состоит из множества программных модулей, включая
диспетчер ввода—вывода и группу' компонентов, попадающих под широкое опре-
деление “драйвера”. Диспетчер ввода-вывода определяет модель обработки вво-
да-вывода в NT и выполняет’ функции, общие или необходимые более чем ,щя
одного драйвера. Его главная обязанность состоит в создании IRP. представляю-
щих запросы ввода—вывода, и проводке этих пакетов через различные драйверы
(с возвратом результата вызывающей программе по завершении ввода—вывода).
К драйверам относятся не только традиционные драйверы устройств. нов
файловые системы, сети, именованные каналы и драйверы других типов. Все
драйверы имею!’ общую структуру и взаимодействуют друг с другом и диспетче-
ром ввода—вывода при помощи одного механизма. Диспетчер ввода—вывода
принимает' запросы на ввод—вывод и отыскивает’ нужные драйверы при помощи
системных объектов ввода-вывода, включая объекты—драйверы и объекты- уст-
ройства. Так как драйверы предоставляют ОС одинаковый интерфейс, они могут
располагаться слоями один над другим для достижения модульности и сокраЩС-
ния дублирования кода. Сама система ввода—вывода NT для повышения произ-
водительности работает асинхронно, но предоставляет подсистемам пользой'
тельского режима средства как синхронного, так и асинхронного ввода—выводя
Разработка драйверов для NT отличается от разработки драйверов д1Я
других ОС. так как они должны корректно работать на многопроцсссорнН*
машинах и могут принимать участие в системных процедурах восстановлен!151
после сбоя питания. Тем не менее, все драйверы пишутся гга языке высокой1
уровня, чтобы сократить время разработки и повысить переносимость. Следу'0'
гцая глава посвящена поддержке сетей в Windows NT; эта тема включает обсуЯ"
дение двух особых драйверов; редиректора и сервера Windows NT.
ГЛАВА 9
СЕТЬ
Пока шла разработка Windows NT, идя по коридорам в помещениях, которые
занимала команда разработчиков, можно было чуть не на каждом втором уви-
деть фирменные футболки Microsoft. 'Гам, где размещалась группа сетей, чаще
всего встречалась футболка с таким рисунком1:
ЛИТ
We're building it in.
До недавнего времени поддержка сетей для персональных компьютеров
обычно добавлялась к существующей ОС. когда возникала необходимость в
межкомпыотерных коммуникациях. Например, Microsoft LAN Manager иногда
называют “сетевой ОС ”, но на самом деле это набор сложных программ и драй-
веров, добавляющих сетевые возможности к существующим ОС, в частности, к
MS-DOS. OS/2 и UNIX. Он предоставляет такие средства, как учетные записи
пользователей, защита ресурсов и механизмы межкомпыотерных коммуника-
ций, включая именованные каналы и почтовые ящики. Хотя п|эедыдущнс версии
LAN Manager и до сих пор выполняют эти важные функции для других (XI, в
Windows NT сетевое программное с юсспеченис более не представляе т собой над-
стройку над ОС. Теперь оно являет ся неотъемлемой частью исполнительной сис-
темы NT. и перечисленные выше возможности включены в состав средств ОС.
Итак, что же означает встроенная сетевая поддержка? На этот вопрос су-
ществует’ несколько <ггвстов, основной из которых состоит в том, что прсярамм-
нос обеспечение одноранговой сет и (также называемое программным обеспе-
чением для рабочих групп) включено в продукт Windows NT. Система оснащена
поддержкой копирования файлов, электронной почты и удаленной печати, ко-
1 Воспроизведено с jioixrnina. p;i3pa6oiainioio ,1ж<> Велфпором Цис Belfiore) и Дэвидом Тьюпи
мэном (David Turanian j. (Надпись перевод»пся как Сен» мы ее вставляем. — Прим, псрев >
торам не требует от пользователя установки какого-либо специального цр0
[ра.ммпого обеспечения. 'Гак как поддержка сети является неотъемлемой ч.ц,
тыо (М2, то сетевое программное обеспечение д ня повышения производитель,
ностн может задействовать внутренние интерфейсы системы, используем i„t
другими компонентами исполнительной системы NT. Эта тема ниже обсужд;1.
ется более подробно.
Помимо встраивания сетевой поддержки в ОС, определяющая цель сеге,
вой архитектуры КГ, по словам Дэйва Томпсона (Dave Thompson), руководите.^
группы сетей NT, состояла в том, чтобы предоставить производителям сетевого
программного и аппаратного обеспечения возможности технологии “включи^
и работай” (Plug&Play) в КГ. 11од этим он подразумевает, что существующие сети
драйверы сетевых плат и сетевые серверы (такие как Novell NetWare. Banyan
VINES и Sun NFS) способны легко взаимодеиспювать и обмет шваться данными t
системами Windows NT. Поскольку требуется поддерживать такое большое количе-
ство сетевых протоколов, плат п драйверов, Microsoft приходится полагаться на
помощь других производителей в разработке различных компонентов сетевого
программного обеспечения Windows NT Эта задача облегчается тем, что Windows
NT содержи т механизмы динамической загрузки и вьпрузки встроенной сетевой
поддержки; те же самые механизмы могут использоваться для загрузки и выгрузки
сетевого нрофаммного обеспечения других производителей.
Помимо обеспечения загрузки (и выгрузки) сетевого программного обес-
печения, в цели разработки поддержки сети Windows NT входило:
Обеспечить взаимодействие с существующими версиями LAN Manager,
работ ающими под другими ОС.
• Обеспечить приложениям дос туп к иным, чем Microsoft, файловым си-
стемам па сетях, отличных от LAN Manager, без изменения кода.
Обеспечить надлежащие средства для создания распределенных про-
мышленных приложений, таких как Microsoft SQLServer, приложений
обработки транзакций и т. д.
В данной главе представлены некоторые особенности сетевой поддержки
Windows NT, делающие се уникальной. В первом разделе описаны основные
сетевые компоненты и их связь с предыдущими сетевыми продуктами Microsoft
Второй раздел посвящен дальнейшему обсуждению понятия “встроенная сете-
вая поддержка”. В третьем разделе обсуждается от крытая сетевая архитектур’
Windows NT, которая позволяет динамически загружать различные сетевые ком-
поненты, такие как LAN Manager и NetWare. В четвертом разделе описаны неко-
торые средства поддержки распределенных приложений в Windows NT, в том
числе именованные каналы, почтовые ящики и удаленный вызов процедур- ®
последнем разделе рассматриваются продвинутые сетевые возможности
Windows NT и средства распределенной защит ы, необходимые для поддержк11
больших корпоративных вычислительных сетей.
Основы
Сети — это сложная тема, изобилующая историческими отступлениями и акро-
нимами, несмотря на то, что вся история вычислительных сетей насчитывает
Глава 9. Сеть
всего лишь около двух десятилетий. В своем младенчестве есть - это были
Просто два компьютера, соединенные проводом, по которому можно было пе-
ресылать файлы. С течением времени производители компьютеров разработа-
ли уникальные сетевые архитектуры. которые работали с их собственными
системами, по не с системами других типов. В наши дни, однако, обычным
делом является наличие у одного человека пли в организации смеси из различ-
ного вычислительного оборудования, все составляющие которой должны вза-
имодействовать друг с другом.
Некоторым образом задача сочетания различных сетевых архитектур сход-
на с проблемой, связанной с тем, что ОС должна поддерживать разнообразные
типы устройств ввода—вывода. Возникает несовместимость, и т ребуется устано-
вить модель, которой будут соответствовать различные компоненты. В Windows
NT сетевое программ! кх обеспечение реализовано большей частью как “хит -
рые” расширения системы ввода-вывода. Это имеет смысл, если рассматривать
сетевую поддержку как средства, при помощи которых пользователи и прило-
жения могут осуществлять доступ не только к локальным, но и к удаленным ре-
сурсам, т аким как файлы, устройства и, наконец, процессоры.
Прежде чем обратиться к сетевой поддержке Windows NT, в следующих
двух разделах мы рассмотрим предшественников некоторых сетевых компо-
нентов Windows NT и то, как эти компоненты встраивают ся в стандартную сете-
вую модель.
9.1.1 История2
Начало истории сетей Microsoft было положено в MS-DOS версии 3.1. В ней к
файловой системе FAT были добакчены необходимые расширения блокировки
файлов и записей, которые обеспечили возможность работать с файлами MS-
DOS сразу нескольким пользователям. Одновременно с выходом в 1984 году вер-
сии MS-DOS 3-1 Microsoft выпустила продукт под названием Microsoft Networks,
который полущил неформальное название ’’MS-NET”
MS-NET установила ряд т радиций, которые были перенесены в LAN Manager,
а теперь и в Windows NT. Например, когда пользователь пли приложение выда-
вали запрос ввода—вывода для удаленного файла, каталога или принтера, MS-
DOS определяла это и направляла запрос компоненту MS-NET под названием
редиректор (redirector). Редиректор MS—NET принимал запрос и посылал, пли
перенаправлял (“redirect”) его на удаленный сервер. В состав сет евой поддержки
Windows NT также входит редиректор, но полностью переработанный и гораз-
до более сложный. На самом деле Window's NT может поддерживать несколько
редиректоров, каждый из которых направляет запросы ввода-вывода удален-
ным файловым системам или устройствам.
Другой частью MS-NET, дошедшей до Windows NT, является протокол SMB
(server message block). Проще говоря, протокол (protocol) — это набор правил и
соглашений, согласно которым взаимодействуют две сущности (в данном случае
компьютеры). Сетевая поддержка обычно включает несколько уровней прото-
колов, расположенных один поверх другого. В зависимости от того, с какими
компьютерами общается данная система, она можег поддерживать (как это де-
- Часть материала для этого и следующего разделов щтедоставнл Стив Канцлер (Steve Kanzler).
ОСНОВЫ WINDOWS NT
лает Windows NT) несколько различных протоколов на разных уровнях иерар-
хии. Протокол MS-NET SMB — это высокоуровневая спецификация формата с<ь
общений, посылаемых по сети. Для посылки запросов, имеющих структуру
формата SMB, на другой компьютер используется API под названием интерн
фейс NetBIOS (NetBIOS interface). Впоследствии как протокол SMB, так н Лр[
NetBIOS были использованы в многочисленных сетевых продуктах, в том чис-
ле и в Windows NT.
I 1ослсднсе, что было перенесено из MS-NET — это сетевой сервер (netw< .ф
server). Сетевым сервером в MS-NET было программное обеспечение, когорт
находилось на удаленном компьютере, превращая его в выделенный файл-сер-
вер и сервер печати. Это программное обеспечение просто контролировало
сетевое соединение и ждало поступления по нему SMB. Затем оно распаковыва-
ло их, определяло, что они запрашивают, выполняло операцию (например, чте-
ние файла), после чего посылало результат обратно в виде другого сообщения
SMB. ЧЕрмин сервер (server) в контексте сетей часто используется для обозначе-
ния компьютера, предназначенного для приема запросов от удаленных компью-
теров. Однако Вы можете рассматривать сетевой сервер как функциональный
эквивалент локального сервера (защищенной подсистемы в терминологии
Windows NT), который принимает запросы от процесса на другой, а не на той
же самой машине.
Встроенная сетевая поддержка Window's NT включает базовый одноранго-
вый сервер, использующий протокол SMB (что делает его совместимым с MS-
NET и LAN Manager). Кроме того. Windows NT может загружать другие сетевые
серверы и выполнять их однов|эемепно со встроенным. Для сложных или боль-
ших сетей будет’ выпущен дополнительный продула; имеющий рабочее название
IAN Manager for Window s NT Он будет превращать одноранговую рабочую стан-
цию в продвинутый сервер домена. Сервер домена способен использовать об-
щую информацию об учетных записях пользователей и установках защиты с
несколькими компьютерами, объединенными в сетевой домен (network domain),
и с другими доверяемыми сетевыми доменами Он также предоставляет средства
создания отказоустойчивых дисков и другие возможности. Благодаря этому
Windows NT соответствует потребностям больших корпоративных сетей* *.
Кстати, MS—NET также включала набор утилит и синтаксис командной стро-
ки для доступа к удаленным дискам и принтерам. Как Вы могли догадаться, сюда
относятся команды вида NET USE X: \\SERVER\SHARE. Имена, начинающиеся <<>
строки \\, по—прежнему обозначают сетевые ресурсы и называются именами
единого соглашения об именышнии (uniform naming convention, I :NC).
9.1.2 Опорная модель OSI
В классической кише С’о/w/utter Networks Эндрю Танснбаума вычислительна
сеть определена как “связанная группа автономных компьютеров’’^ Это
|
* Так как книга писалась одповрсмсчпю с разработкой системы. ллор не могла знал», что к моменп
птэвностн будет ш^дготглшепо дж* версии ОС — Windows КГ и Windows NT Advanced >erver. Имени0
нек'ледннй (mvkvvict теми свойствами, о мупэрых пишет Хелен. В пскиюдувмцнх версиях название бы.'1°
изменено Рабочая станция, обзадлиицая о.щорзнпэвыми сетевыми нозмоизюстямн, называется Wind0"4
ЬГГ \Хorkstation. а сервер, сткксюный выступать в рент контроллера домена, Windows NT Scrvci.
4 Andrew S. Tanenbaum, Computet' Aietteorks, 2d rd. (hnglcwood Clifts, NJ.: Prentice Hall, 198е)), 2
чает, что каждый компьютер работает самостоятельно под управлением соб-
ственной ОС. Именно для такой среды и разработана сетевая архитектура
Windows NT.
Задача сетевого программного обеспечения состоит в приеме запроса
(обычно это запрос ввода—вывода) от приложения па одной машине, передаче
его на другую машину, выполнении запроса на удаленной машине н возврате
результата на первую машину. В ходе этих операций запрос несколько раз пре-
образуется. Высокоуровневый запрос, например, “прочитать х байтов из файла
у на машине z” требует, чтобы программное обеспечение определило, как дос-
тичь машины z и какой коммуникационный протокол она понимает. Затем за-
прос должен быть преобразован для передачи по сети: например, разбит на ко-
роткие пакеты информации. Когда запрос достигнет другой стороны, необхо-
димо проверить его целостность, декодировать и послать на выполнение соот-
ветствующему компоненту ОС. По окончании запрос должен быть закодирован
для обратной передачи по сети.
Чтобы помочь производителям в стандартизации и интегрировании их се-
тевого программного обеспечения, Международная организация по стандар-
тизации (ISO) определила программную модель пересылки сообщений между
компьютерами. Эт а модель получила название Опорной модели соединения от-
крытых систем — Open Systems Interconnection (OS1) reference model. В модели
определены семь уровней программного обеспечения, как показано на рис. 9—1.
Машина-клиент
Машина-сервер
Рис. 9-1. Опорная модель OSI.
Опорная модель OSI является идеальной схемой, которая в точности реа-
лизована на очень немногих системах, по часто используется при обсуждении
основных принципов работы сети. Каждый уровень на одной из машин считает,
что он “разговаривает" с тем же самым уровнем на другой машине. На данном
уровне обе машины “разговаривают” на одном и том же языке, пли протоколе.
Однако в депствителы юстп сетевой запрос д< >лже1i ci густиться д< > сам< >го нижне-
го уровня на клиентской машине, затем он передается по физическому носите-
лю и вновь поднимается на серверной машине до уровня, который его поймет
и обработает.
Задача каждого уровня состоит в том, чтобы предоставить обслуживай^
верхним уровням, абстрагируясь от того, как реализовано это обслуживание 1(.
нижних уровнях. Подробное обсуждение назначения каждого уровня выходцу О
рамки данной книги, однако ниже приводится краткое описание этих урови^
а Прикладной уровень. Обрабатывает передачу данных между двумя С(. 1
тевымп приложениями, включая проверку прав доступа, идентпфщ.. '
цню взаимодействующих машин и инициирование передачи даниц»
Уровень представления. Отвечает за форматирование данных, г,
числе решает, должны ли строки заканчиваться парой символов
врат каретки/перевод строки” (CR/LF) или только символом “во:;ира.(:
каретки” (CR); должны ли данные быть сжаты или закодированы и |. ((
• Ceai 1совый уровень. Управляет соединением между взаимодействуй >111и.
ми приложениями, включая синхронизацию высокого уровня н кощ.
роль за тем. какое из приложений “говорит”, а какое “слушает”.
Транспортный уровень. Разбивает сообщения на пакеты и присваиваетI
последним номера, чтобы гарантировать их прием в надлежащем по-
рядке. Кроме того, изолирует сеансовый уровень от влияния аппаратур.'
пых изменении.
Сетевой уровень. Отвечает за маршрут! 1зацию. управление интенш шно-
стью лрафика и межсетевой обмен. /Это самый высокий из уровнен, по
Машина-клиент
Машина-сервер
7 Прикладной
6 Уровень
представления
5 Сеансовый
4 Транспортный
3 Сетевой
2 Канальный
1 Физический
Рис. 9-2. Модель OSI и сетевые компоненты Windows NT.
нимающих топологию (topology) сети, т. е. физическую koi 1фи1у ра-
цию машин в пси, тип физических соединений между ними и ограни-
чения щюпускноп способности, длины используемых кабелей и т. д.
Канальный уровень. Пересылает низкоуровневые кадры данных, ожи-
дает подтверждений их получения и повторяет передачу кадров, поте-
рянных в ненадежных линиях связи.
Физический уровень. Передает биты по сетевому кабелю или другой
физической передающей среде.
Пунктирными линиями на рис. 9-1 показаны протоколы, используемые
для передачи запроса на удаленную машину. Выше уже говорилось, что каждый
уровень иерархии считает, что он общается с аналогичным уровнем на другой
машине и использует некоторый стандартный протокол. Набор протоколов, в
соответствии с которыми запрею проходит вниз по уровням сети и обратно,
называется стекам протоколов (protocol stack).
На рис. 9—2 представлен общий вид сетевых компонентов Windows NT, их
соответствие уровням модели OSI, а также протоколы, используемые различны-
ми уровнями Изображенные на рисунке компоненты описаны далее в этой главе.
Из рисунка видно, что уровни OSI неточно соот ветствуют реальным про-
граммным модулям. Транспортное программное обеспечение, например, часто
пересекает границы нескольких уровней. Фактически слово “транспорт” час-
то используется как общее обозначение всех четырех нижних уровней. Ком-
поненты, расположенные на т рех верхних уровнях, называются “пользовате-
лями транспорта”.
Остальная часть этой главы посвящена описанию сетевых компонентов,
изображенных на рис. 9-2 (а также некоторых, не показанных на рисунке), их
взаимосвязи и роли в Windows NT.
Встроенная сетевая поддержка
Из предыдущего раздела стало ясно, каким образом некот орые сетевые компо-
ненты Windows NT соотносятся со справочной моделью OSI. На рис. 9—3 пока-
зано место этих компонентов в архитектуре Windows NT.
Программы пользовательского режима (например, API ввода-вывода
Win32) выдают запрею на удаленный ввод-вывод, вызывая базовые сервисы вво-
да-вывода NT. После некоторой предвари тельной обработки (которая описана
ниже) диспетчер ввода—вывода создает пакет запроса ввода—вывода (IRP) и пе-
редает’ его одному из зарегистрированных драйверов файловой системы, в
данном случае редиректору Windows NT. Редиректор направляет пакет драйве-
рам нижнего уровня (драйверам транспортов), которые обрабатывают его и
передают по сети.
Когда запрос приходит на машину, работающую под управлением
Windows NT, он принимается драйверами транспорта, после чего проходит еще
через несколько драйверов. На рис. 9—1 показан прием сетевого запроса на за-
пись. Запрею па чтение должен пройти на сервере ют же путь с возвращением
данных обра тно. Более подробно редиректор, сервер и драйверы транспортов
обсуждаются ниже в этой главе.
Приложение,
подсистема
или DLL
Сервисы системы ееодо-еь/еода NT
Пользовательски^
___________режим
\
5 ‘
Менеджеры i
ввода-вывода •
_____________1______
Файловая
система
редиректора
Интерфейс драйвера
транспорта (TDI)
Режим ядра
_____
Драйверы
сетевых
транспортов
------t-----
Драйверы
NT
— — ► К сети
Рис. 9-3. Упрощенное изображение клиентской стороны сетевого ввода-вывода.
9.2.1 Сетевые API
Рассмотрим, каким образом приложение получает доступ к сети. Windows NT
предоставляет для этого несколько способов-.
API ввода-вывода Win32. Функции ввода—вывода выполняют стандарт-
ные функции открытия, закрытия, чтения, записи и т. д. Соответствую-
щие запросы I [роходят по сети только в том случае, когда файл или име-
нованный канал находятся на удаленной машине. Как правило, это оз-
начает, что имя файла является именем UNC или начинается с буквы,
указывающей на диск на удаленной машине.
Сетевые API Win32 (WNct). Эти функции полезны таким приложения'1,
как File Manager, которые выгюлняют соединение с удаленными фагкю-
выми системами и их просмотр. Функции WNct можно использовать
для просмотра файловых систем Microsoft и других по сетям LAN
Manager, NetWare, VINES и т. д.
е Win32 API именованных каналов и почтовых ящиков. Именованные ка-
налы обеспечивают высокоуровневый интерфейс передачи данный
между двумя процессами, независимо от того, является ли принимаю-
щая сторона локальной или удаленной. Почтовые ящики выполняю^
Пользовательский
режим
Режим ядра
Системные сервисы
Менеджеры ввода-вывода
Вызвать следующий драйвер
“Файловая
система"
сервера
Скопировать
данные в буфер
_______I_____
Драйверы
сетевых
транспортов
А------
I
От сети . — "
Драйверы
NT
_____1____
Драйвер
локальной
файловой
системы
Диск
Рис. 9-4. Упрощенное изображение серверной стороны сетевого ввода-вывода.
аналогичные функции, однако вместо обеспечения канала “один к од-
ному” между' принимающей и передающей сторонами они предостав-
ляют механизмы связи “один ко многим” и “многие к одному7”. Почто-
вые ящики полезны для посылки широковещательных сообщений про-
извольному7 числу процессов.
• API NetBIOS. Эти API обеспечивают' обратную совместимость для тех
программ MS-DOS, 16—разрядной Windows и OS/2, которые пере-
дают данные непосредственно по сети. Имеется также новая 32-
разрядная версия.
API Windows Sockets. Эти API реализуют 16 и 32—разрядные сокеты —
стандартный сетевой интерфейс, используемый UNIX. Windows NT так-
же содержит код нижнего уровня, обеспечивающий поддержку прило-
жений UNIX и позволяющий легко осуществлять доступ к глобальной
сети Internet.
* Средство удаленного вызова процедур (RPC). Соответствующая биб-
лиотека периода выполнения и компилятор позволяют программис-
там с легкостью создавать распределенные приложения (подробнее
см. разд. 9 4-1 )
Путь каждого из АР] к сети пролегает по разным маршрутам. На рис. 9—5
показаны функции ввода—вывода Win32, которые эта подсистема реализует пу-
ОСНОВЫ WINDOWS Nl
тем вызова базовых сервисов системы ввода—вывода NT'. Далее диспетчер p.i4)
да-вывода посылает IRP редиректору В отличие от этого, API Windows Sockets h
NetBIOS реализованы как DLL, которые вызывают сервисы ввода-вывода NT.
—>/< сети
Рис. 9-5. Разные маршруты доступа к сети.
' Обратите внимание, что большая часть функций API Vi m32 отимизирована в DIJ. клиентской
стороны и в действительности нс обращается к подсистеме Win32. Подробнее см. гл. 5, “Windows >*
защищенные подсистемы”
диспетчер ввода-вывода направляет IRP драйверам Windows Sockets и NetBIOS
соответствен! ю.
Как показано на рис. 9-5, вызовы API WNct (реализованного в виде DLL)
I ipo-ходят через сетевой компонент, называемый се/жисам рабочей спипщин (work-
station service). На сетевом жаргоне термин серине (service) обозначает сервер-
ный процесс, выполняющий некую конкретную функцию (в смысле “работу”) и,
возможно, экспортирующий API. который поддерживает эту функцию. Сервисы
ВВП 1СЛ!1ЯЮТ СЛСДуЮППIC фУ1 IKI (ИИ:
Адми!(истрнрованис встроенного редиректора — сервис рабочей стан-
ции и сервера — сервис сервера (server service).
Рассылка оповещений подключенным пользователям — сервис опове-
щений (alerter service), например, при переполнении жесткого диска.
И Прием сообщений от других систем сервис сообщений (messenger
service), например, уведомлений о том. что завершено выполнение за-
дания на печать.
Сервис — это процесс, похожий на защищенную подсистему Windows NT.
Некоторые сервисы просто выполняются в фоновом режиме, в то время как
другие предоставляют API, которые могут вызывать потоки других процессов,
посылая сообщения данному сервису. В отличие от защищенных подсистем,
сервисы, имеющие собственные API, для обмена сообщениями со своими клиен-
тами обычно используют RPC, а не LPC. Применение RPC делает сервисы доступ-
ными процессам как на локальной, л ак и на удаленной машине (подробнее см.
разд, 9.4.1).
Сервис рабочей станции является, в сущности, надстройкой пользователь-
ского режима для редиректора Windows NT. Он поддерживает АР) WNct, предо-
ставляет функции конфигурации редиректора и содержит код пользовательско-
го режима для получения ст атистики редиректора. Когда приложение вызывает
функцию API WNet, этот' вызов вначале поступает сервису рабочей станции, а
затем уже к диспетчеру ввода—вывода NT и далее к редиректору.
За загру'зку и запуск сервисов Windows NT отвечает компонент, называе-
мый контроллером сервисов (service controller). Он также предоставляет сред-
ства загрузки и выгрузки драйверов, кот орые не загружаются при запуске систе-
мы. Muonic сетевые компоненты реализованы в виде драйверов и, таким обра-
зом, загружаются в систему (и удаляются из нее) контроллером сервисов.
9.2.2 Встроенные сетевые компоненты
Хел я за поддержку сети отвечают многие компоненты Windows NT, наиболее
важны из них те, которые имеют в Microsoft самую долгую историю: редирек-
тор и сетевой сервер. Как и в оригинальной MS—NET, редиректор посылает ло-
кально выдаваемые запросы удаленному серверу, а сервер принимает и обра-
батывает их.
Конечно, кроме названий, мало что в сервере или редиректоре напомина-
ет прежнее программное обеспечение. Первые варианты были написаны на
языке ассемблера и выполняли роль надстройки над MS-DOS. Несмотря на то,
что новые сервер и редиректор встроены в Windows NT, они нс зависят от аппа-
ратной архитектуры, па которой выполняется ОС. Они написаны на языке С н
ОСНОВЫ WINDOWS NT
реализованы в виде загружаемых драйверов файловых систем, которые moiV)
загружаться и выгружаться динамически. Кроме того, они могут сосуществовав
с серверами и редиректорами других фирм.
Реализация редиректора и сервера в виде драйверов файловой системы
лает их частью исполнительней системы NT. В связи с этим они имеют досгуц (
специализированным интерфейсам, которые предоставляет драйверам днепр,
чер ввода-вывода. В свою очередь, данные i и перфейсы разрабатывались с учс-щ*
потребностей сетевых компонентов. Эта возможность доступа к интерфейса*,
драйвера плюс способность прямого вызова функций диспетчера кэша внося-,
существенный вклад в повышение производительности сервера и редиректора
Послойная модель драйвера диспетчера ввода-вывода напоминает сг1е.
ственное расположение сетевых протоколов один над другим. Поскольку реднрек.
тор и сервер являются драйверами, под ними может быть расположено eio.;IhK0
слоев драйверов протоколов, сколько необходимо. Такая структура обеспечивает
модульность сетевых коли юнентов и создаст эффектнытыс i тереходы отурош ш ре.
директора или сервера вниз к транспортным и физическим уровням сети.
9.2.2.1 Редиректор
Сетевой редиректор предоставляет средства, необходимые машине с Window
NT для доступа к ресурсам на другой машине в сети. Редиректор Windows МТ
может осуществлять доступ к удаленным файлам, именованным каналам и прин-
терам. Благодаря тому, что в нем реализован протокол SMB, редиректор может
работать с существующими серверами MS-NET и LAN Manager, обеспечивая
Window’s NT доступ к системам MS-DOS, Window's и OS/2. Механизмы защиты
гарантируют, что данные Windows NT, совместно используемые через сетевое
соединение, будут защищены от несанкционированного доступа.
Будучи драйвером файловой системы, редиректор работает, как и любой
другой драйвер. Когда он загружается в систему, его процедура инициализации
создаст объект-устройство (под названием \Dei,ice\Redirectoi'') для представления
редиректора в системе. Кроме того, процедура инициализации определяет коды
функций, поддерживаемых редиректором, и записывает т очки входа драйвера
(процедуры распределения) для этих операций. Когда диспетчер ввода—вывода
получает сетевой запрос ввода—вывода, он создаст JRP и вызывает одну’ из про-
цедур распределения редиректора, передавая ей этот пакет. После того как реди-
ректор обработает запрос (посредством обращения к сели), 1RP завершается, 11
результаты возвращаются вызывающей программе.
В промежутке между посылкой запрела и получением ответа у' редиректо-
ра есть одна основная задача-, предоставить “файловую систему”, которая нсд^
себя как локальная файловая система, хотя и работает с ненадежным по сипе’1
природе целителем (сетью). Физическое соединение между двумя компьют ер'1'
ми нарулпается значительно чаще, чем связь между компьютером и его жест»1
диском или приводом гибких дисков. При нарушении связи редиректор ел неча-
ст за ее восстановление, если это возможно. или за корректную обработку со0*1
позволяющую приложениям повторно выполнить текущую операцию. Для э'1’1’1
цели редиректор применяет различные методы. Например, при потере связ'1 f
сервером он просто восстанавливает ее. Кроме того, он запоминает, какие Ф:11
лы были открыты и при определенных обстоятельствах открывает их сно^
(Драйверы транспортов, лежащие ниже редиректора, обесггечивают iгадежно^^
передачи данных па уровне битов.)
Как и другие драйверы файловых систем, редиректор дсуоксн соответство-
вать асинхронной .модели ввода-вывода, поддерживая выполнение асинхрон-
ных запросов ввода-вывода. Когда запрос пользовательского режима выдастся
асинхронно (как описано в гл. 8. “Система ввода-вывода”), редиректор должен
вернуть управление немедленно, независимо от того, завершена ли удаленная
операция ввода—вывода. В большинстве случаев удаленный запрос ввода—выво-
да не завершается сразу же, поэтому, вернув управление вызывающей програм-
ме, редиректор должен ждать его завершения. Парадоксально, но код драйвера
всегда активизируется вызывающим потоком, в контексте этого потока. У него
нет адресного пространства своих потоков или каких-либо еще. Каким же об-
разом драйвер может вызвать процедуру ожидания?
Данная проблема не уникальна для редиректоров; болыпинст во драйверов
файловых систем сталкиваются стой же дилеммой. В первоначальном варианте
системы ввода-вывода драйверы файловых систем, которым нужно было вы-
полнять обработке' в своем собственном контексте, просто создавали процесс
режима ядра, связанный с драйвером, и использовали его потоки для асинхрон-
ной обработки. Однако такой подход оказался слишком дорогим с точки зрения
использования системной памяти. Поэтому было придумано новое решение.
У Windows NT имеется специальный сист емный процесс для инициализа-
ции системы во время се загрузки. В этом процессе есть несколько рабочих
потоков, ожидающих в цикле поступления запросов от драйверов и других ком-
понентов исполнительной системы, которые и выполняют асинхронную рабо-
ту. Если для выполнения асинхронной работы драйверу нужен поток, он поме-
щает задание в очередь этого специального процесса, прежде чем вернуть уп
равление вызывающей программе. Поток системного процесса пробуждается т
выполняет операции, необходимые для обработки запроса ввода-вывода и за
вершения IRP исходной вызывающей программы.
Для выполнения своих задач редиректор отправляет и принимает SME
Хотя на рис. 9—2 редиректор и сервер изображены для простоты как компонен
ты сеансового уровня модели OSI, на самом деле протокол SMB является прото
колом прикладного уровня, как показано на рис. 9—6.
Интерфейс, через который редиректор посылает свои SMB, называете
интерфейсом драйвера транспорта (transport driver interface, TDI). Редиректор
вызывает TDI для i юредачи SMB различным драйверам транс! юрта, загруженньн
в систему. Для того, чтобы вызвать функции TDI, редиректор должен открыт ь дл
связи с удаленной машиной канал, называемый виртуальным контуром (virtu;
circuit), и зат ем посылать SMB через этот контур. Редиректор поддерживает п
одному виртуальному контуру'для каждого сервера, с которым связана Window
NT, и мультиплексирует все запросы к данному серверу' в один контур. Транспорт
ный уровень, pact излагающийся t юд редиректором, определяет способы реал! гз;
ции виртуального контура и посылает данные через сетевое соединение.
Редиректор для Windows NT разработал Лэрри Остерман (Larry Osterman
который в свое время трансформировал редиректор MS-NET в редиректор LA
Manager 1.0, а пот ом переписал его и для LAN Manager 2.0. Помимо повышен!
надежности, от него также требовалось обеспечить стопроцентную совместт
мость с существующим протоколом SMB. Для выполнения этих требований с
использовал все тот же протокол для передачи сообщений серверам старых м<
делей (MS—NET и LAN Manager). Сохранение этого базового протокола позвол
ет Windows NT взаимодействовать с серверами Window's, OS/2 или MS-DOS, раб
новь
IN DOWS NT
Машина-клиент
Машина-сервер
7 Прикладной
6 Уровень
представления
5 Сеансовый
4 Транспортный
3 Сетевой
2 Канальный
1 Физический
Рис. 9-6. Использование протокола SMB.
тающими под LAN Manager. Для обмена данными между системами Windows NT
Лэрри расширил базовый протокол SMB для поддержки распространенных опе-
раций системы ввода-вывода NT. Например, расширенный протокол способен
поддерживать такие спет 1ифичпые для NT onepai (ии, как открытие файла с дос-
тупом для удаления, открытие каталога, присоединение к файлам списков управ-
ления доступом (ACL) в целях их защиты и выполнение операций опроса для
получения информации о файлах. В дополнение к этому новый протокол SMB
передает строки в символах UNICODE, чтобы гарантировать правильную пере-
дачу символов иностранных языков.
9.2.2.2 Сервер
Как и редиректор, сервер Windows NT создавался так, чтобы обесг гсчить ctoi про-
центную совместимость с существующими протоколами SMB MS-NET и LAN
Manager. Полная совместимость позволяет серверу обрабатывать запросы, ирП'
ходящие нс только от систем Windows NT, по также и от других систем, на ко-
торых работает программное обеспечение LAN Manager. Подобно редиректору
сервер реализован в виде драйвера файловой системы.
Может’ показаться странным, что нечто, называемся? “сервером”, не реали-
зовано в виде серверного процесса. Резонно было бы предположить, что сето
вой сервер должен работат ь как защищенная подсистема — процесс, чьи потоки
ожидают поступления запросов из сети, выполняют их и возвращают результат"*11
обратно в сеть. Такой подход был наиболее очевиден, и Чак Ленцмайер (Chuck
Lenzmeicr) тщательно рассмотрел его, начиная разработку сервера Windows N'1
Глава 9. Сеть
Но вместо этого Чак. основной разработчик сервера, имевший к тому времени се-
милетий опыт работы с сстями u RPC па VAX/VMS, решил реализовать сервер как
драйвер файловой системы. Хотя сервер не является драйвером в обычном смысле
и не управляет какой-либо файловой системой, использование модели драйвера
имеет своп преимущества по сравнению с реализацией сервера в виде процесса.
Основным преимуществом является то, что сервер находится в исполни-
тельной системе NT и может непосредственно вызывать диспетчер кэша для оп-
тимизации передачи данных. Например, если сервер получает запрос на чтегн гс
большого объема данных, он вызывает диспетчер кэша, чтобы найти в кэше нуж-
ные данные (ivni загрузить с диска, если их нет в кэше) и зафиксировать их в
памят и. Зат ем сервер передает данные в сеть непосредственно из кэша, избегая
лишних обращений к диску или копирования. Аналогично, при поступлении за-
проса па запись данных сервер вызывает диспетчер, чтобы выделить для посту-
пающих данных место в кэше и получить адрес этого места. Затем сервер запи-
сывает данные непосредственно в кэш. Благодаря записи данных в кэш, а нс па
диск сервер может быст]тес вернуть управление вызывающей программе; дис-
петчер кэша затем пересылает данные па диск в фоновом режиме (используя
средства подкачки страниц диспетчера виртуальной памяти).
Вызывая диспетчер кэша, сервер фактически бере г на себя некоторые обя-
занности диспетчера ввода-вывода для упрощения обработки. Кроме того, сер-
вер играет роль диспетчера ввода—вывода, создавая собственные 1RP и посылая
их непосредственно драйверам NITS, FAT и HPFS. Он может принять решение
непосредственно пересылать данные в кэш и из кэша, не создавая IRP. Если бы
сервер был подсистемой пользовательского режима (пли даже режима ядра),
ему пришлось бы для обработки поступающих запросов вызывать сервисы вво-
да-вывода NT, что связано С несколько большими накладными расходами.
Будучи драйвером файловой системы, сервер также более гибок, по срав-
нению с процессом. Например, он может зарегистрировать процедуру заверше-
ния ввода—вывода, что дает ему возможность быть вызванным сразу же, как толь-
ко драйверы нижнего уровня завершат' обработку, и выполнить необходимые
завершающие действия. Несмотря на то, что сервер Windows NT реализован в
виде драйвера файловой системы, другие серверы могут быт ь как драйверами,
так и серверными процессами.
Подобно редиректору, сервер использует начальный системный процесс
для обработки асинхронных операций ввода-вывода и тех периодически встре-
чающихся “дорогих” операций, выполнение которых нс требует максимальной
скорости — например, от крытия файла. Операции, требующие высочайшей ско-
рости выполнения, такие как чтение нлн запись, исполняются, если возможно,
непосредст венно в драйвере, чтобы избежать накладных расходов, связанных с
переключением контекста. Несмотря на необходимость переключения контек-
ста, использование начального системного процесса для выполнения сетевых
операций позволяет серверу при нсобходпмост и ждать у описателей объектов
или генерировать страничные ошибки, чего он не может сделать, выполняясь в
контексте другого потока на повышенном 1RQL. Возможность генерации стра-
ничных ошибок означает, что мсныпая часть кода сервера должна оставаться
резидентной в памяти.
При запуске Windows NT диспетчер ввода-вывода загружает те драйверы,
которые требуются на ранних стадиях загрузки системы (драйверы файловой
системы п диска, видеодрайвер, драйверы мыши и клавиатуры). После того, как
процесс зафузки системы продвинется достаточно далеко, чтобы переключи ,ь
ся из режима ядра в пользовательский режим, для загрузки остальных драй)1с
ров, включая редиректор, сервер и драйверы транспортов, вызывается коит|Х)Г|
лер сервисов. Он загружает эти драйверы, вызывая сервисы системы ввода- BljJ
вода, которые копируют драйверы в память и выполняют процедуры их нпищ,
ализации. Процедура инициализации каждого драйвера создает объект-уецхтй.
ство и помещает его в пространство имен диспетчера объектов. Контроллер сер.
висов можно также вызвать в любой момент работы системы для загрузки и р1Ь.
грузки сетевых серверов или для запуска и останова сетевых сервисов.
Разрешение имен
Одна из главных задач Windows NT — распространить действие локальной си-
стемы ввода-вывода на удаленные ресурсы. Так как все такие ресурсы — Это
объекты, для доступа к ним локальное программное обеспечение должно рабо-
тать с локальной структурой объектов. Когда приложение открывает файл, оно
на самом деле открывает описатель файлового объекта NT Файловый объект
содержит данные, специфичные для данного “открытого экземпляра” файла,- на-
Iтример, такую информацию, как режим совместного использования и указатель
файла. Если открываемый файл расположен на удаленном компьютере, обра-
ботка выполняется так же. Диспегчер объектов принимает в пей участ ие, созда-
вая файловый объект и открывая его описатель.
Как и is случае локального файла, имя удаленного файла, от крываемого при-
ложением, должно быть разрешено; это означает, что ОС необходимо опре-
делить, на каком устройстве находится файл, какая файловая система использу-
ется на этом устройстве и где внутри этой файловой системы расположен дан-
т 1ый файл. Для удаленного файла ОС должна также установить, па какой машине
расположен файл и как послать запрос па эту машину.
Предположим, что пользователь назначил удаленному серверу- букву диска,
выдав команду NET I ’SE Т: \\TOOI-SERV\TOOLS. Сервис рабочей станции создает
объект-символическую связь с именем Т: в пространстве имен диспетчера объек-
тов NT, как показано на рис. 9-7-
Рис. 9-7. Пространство имен диспетчера объектов.
После этого приложение Win32 открывает удаленный файл T:\editor.^e'
Подсистема Win32 транслирует это имя в объект NT ^)osDeuices\T:\edit(n-.e.xe "
обращается к исполнительной системе N I для открытая файла. В процессе об"
работки диспетчер объектов определяет, что \DosDevices\T: — это объект—сим1*0'
Глава 9. Сеть
Рис. 9-8. Разрешение сетевого имени файла.
лическая связь и подставляет вместо \DosDevices\T: указанное имя. Как показано
на рис. 9—8. \pevice\Jiedirector — эго имя объекта—устройства, представляющего
редиректор Windows NT, а Т: обозначает удаленный совместно используемый
ресурс LAN Manager, поиск которого будет осуществляться редиректором.
Объекты-устройства используются в NT как точки входа в пространства
имен, не контролируемые диспетчером объектов. Если при разборе имени
объект а диспетчер объектов встречает объект -устройство, то он вызывает ме-
тод разбора, с вязанный с этим устройством. В данном случае метод — э го про-
цедура диспетчера ввода—вывода, вызывающая редиректор. Редиректор создает
SMB и посылает их через драйвер транспорта удаленному серверу- SMB, который
открывает файл \editor£xe в \\TC)01SER\\TO()1S. Диспетчер объектов создает для
представления вновь открытого файла локальный файловый объект н возвра-
щает вызывающей программе его описатель. ГПосле этого все операции с дан-
ным описателем поступают напрямую редиректору NT.
Аналогичное пространство имен существует в системе Windows NT, являющей-
ся пунктом назначения. Удаленное пространство объектов содержит имя \IJeiice\Ser-
i'er, обозггачаюгцее драйвер файле люй атстемы, который реализуетфунющи встро-
енною сервера Windows NT Однако этот объект—устройство не используется при
получег ши сервером запроса; он применяется только тогда, когда в npoi lecce управ-
ления сервером сист емный администратор обращается к нему по имени.
КЗ Открытая архитектура
Так как сетевой сервер встроен в Windows NT, можно решить, что он жестко
“зашит”, и на этом остановиться — но это не так. Определенная Дэйвом Томпсо-
ном цель “включай и работай” требует от Windows NT способности подклю-
чатся к разнообразным сетям. В связи с этим возможна нс только динамическая
загрузка и выгрузка редиректора, сервера и драйверов транспортов, но и одно-
временное выполнение различных компонентов этого типа. Windows NT под-
держивает сети, отличные от IAN Manager, несколькими способами:
« Она обеспечивает доступ к иным, чем Microsoft, файловым системам
для подключения ресурсов и просмотра сети, а также ввод-вывод в
удаленные файлы и устройства через общие API Win32 (API WNct).
ОСНОВЫ WINDOWS NT
Iaobo 9. Сеть
*»' Они допускает одновременную загрузку нескольких драйверов пр<у|()
колов и предоставляет редиректорам общий интерфейс для обрашец11;)
к этим драйверам.
Она предоставляет драйверам сетевых карт интерфейс и среду (\ij]S
3.0) для доступа к драйверам транспортов и обеспечения переносим,,
сто на будущие системы MS -DOS.
В следующих разделах описаны эти возможности и реалпзующц, Их
компоненты.
9.3.1 Доступ пользовательского режима
к удаленным файловым системам
Как было сказано в разд. 9.2.1, API ввода вывода и WNct Win32 предоставляют
приложениям пользовательского режима два способа доступа к файлам (и .ц>\.
гим ресурсам) па удаленных системах. Оба этих API для доступа к сети исполь-
зуют возможности редиректора. Хотя предыдущее обсуждение в первую очередь
касалось встроенной сетевой поддержки, в систему могут быть загружены и до-
полнительные редиректоры для доступа к сетям других типов. В этом разделе
исходная тема расширяется н затрагивает программное обеспечение, которое
решает, какой редиректор вызвать дня обработки запроса на удаленный ввод-
вывод. За это ответственны следующие компоненты:
/Маршруниспппормногосетевого доступе/ (multiple provider router, MPR).
Это DLL, определяющая, к какой сети следует обратиться, когда i ipwio-
женпе использует Win32 API WNct для просмотра удаленной файло-
вой системы.
Акюгосетевод I’NC (multiple UNC provider, МИР). Драйвер, определяю-
щий, к какой сети следует обратиться, когда приложение использует
Win32 API ввода-вывода для открытия удаленных файлов.
9.3.1.1 Маршрутизатор многосетевого доступа для API WNet
Функции WNet Win32 позволяют приложениям (включая Windows File Manager)
подключаться к сетевым ресурсам, таким как файлы и принтеры, а также про-
сматривать содержимое удаленных файловых систем любого типа. 'Гак как этот
API предназначен для работы с различными сетями н по разным протоке >.там.10
должно присутствовать пското|хх.“ программное обеспечение для корректной
посылки запроса по сети и правильной интерпретации результа тов, получаемы*
от удаленного сервера. Программное- обеспечение, отвечающее за выполнсиЩ'
этой задачи, показано на рис. 9 -9.
Компонент сетевого доступа (provider) — это программный компопсп'Г
позволяющий Windows NT выступать в качестве клиента некоторого удаленной’
сервера. Среди операций, выполняемых встроенным компонентом сетевого до-
ступа WNet, можно назвать установление и разрыв сетевого соединения, удалей'
иую печать п передачу данных по сети. В его состав входят DLL, сервис рабочей
станции и встроенный редиректор. От других изготовителей сетей требуется
предоставить только DLL и редиректор.
Когда пр! >Л1 жег ше вызывает пек< тторук > фуню д по WNct, этот вызов i и л шда-
ст нено<. родственно в DLL .маршрутизатора многосетевого доступа (MPR) сете-
вого компонента, разработанного Чако.м Ченом (Chuck Chan). MPR принимает
вызови определят, через какой из компонентов сетевого достут ш WNct можно
осуществите доступ к данному ресурсу. Все- DLL компонентов сетевого доступа
Интерфейс сетевого доступа
DLL встроенного
компонента сетевого
доступа WNet
--------------]----
RPC
Сервис
рабочей
станции
Различные DLL компонентов
сетевого доступа
WNet (Novell. Banyan..)
_____1
Файловые системы
альтернативных
Редиректоров
Пользовательский
режим
Режим ядра
Системные сервисы
-V
Менеджер
ввода вывода ч
Файловая система
встроенного
редиректора
I
л
Интерфейс драйвера транспорта (TDI)
1_____________________I
Сетевые транспорты
------------х----------------------
х
X.
"----------------------->/<сети
Рис. 9-9. Использование нескольких компонентов сетевого доступа.
НОВЫ WINDOWS NT
расположенные ниже MPR, предоставляют набор стандартных функций, которц
называется инте/фгПсом сетевого доступа (provider interface). Данный интер
фейс позволяет MPR определить, к каком сети пытается обратиться приложен,^
и направить вызов соответствующему компоненту сетевого доступа WNet.
Когда MPR вызывается для подключения к удаленному сетевому рес\ |Х,
функцией API WNctAddConncction(), он просматривает реестр конфигурации
чтобы определить, компоненты доступа для каких сетей загружены. Далее он О1]
рашивает их в том порядке, в каком они перечислены в реестре, пока либо одИ(1
из них не распознает сетевой ресурс, либо все они не будут опрошены (поряди
опрсх а можно также изменить путем редактирования базы данных реестра).
Функция WNetAddConncction() может также назначить букву диска уд,,
ленному ресурсу: В этом с лучае она направляет вызов соответствующему постав-
щику сети. Тот, в свою очередь, создает’ объект-символичсскую связь, которцу
отображает данную букву на редиректор (т. е. на драйвер удаленной файловой
системы) для данной сети. На рис. 9-10 показано, как имена сетевых ресурсов
вставляются в пространство имен диспетчера объектов NT.
Подобно встроенному редиректору, другие редиректоры тоже создаю*
объект-устройство в пространстве имен диспетчера объектов во время своей
загрузки и инициализации. Затем, когда WNet или другой API обращается кдис
петчеру7 объектов для открытия ресурса, расположенного на другой сети, Д|,е
петчер использует объект-устройство как точку входа в удаленную файловую
систему. Он вызывает метод разбора диспетчера ввода-вывода, связанный с
объектом-устройством, для поиска драйвера файловой системы редиректор3-
который может обработать данный запрею (дополнительную информацию см ”
гл. 8, “Система ввода—вывода”).
1.2 Многосетевой UNC для файлового ввода-вывода Win32
Многосетевой UNC (MIJP), разработчиком которого является Мэнни Вей31-’!’
(Manny Weiser), — это сетевой компонсл it, сходный с MPR. Он обрабатывает запР1’
сы к файлам или устройствам, содержащие имя UNC (это имена, начинающиеся,
символов \\, которые указывают, что данный ресурс находится в сети). MUP, под1*1
но MPR, определяет, какой локальный редиректор распознает удаленный ресурс
Главе 9 Сеть
Ч"------->/<сети
Рис. 9-11. Многосетевой UNC.
В отличие от MPR, МГР — это драйвер NT (загружаемый при запуске сис-
темы), который выдает запросы драйверам нижнею уровня, в данном случае ре-
директорам, как показано на рис. 9-11.
Драйвер MUP активизируется, когда приложение пытается открыть уда-
ленный файл или устройство, задавая имя UNC (а не переназначенную букву
диска, как описывалось выше в этой главе). Получив подобный запрос, подсис-
тема Win32 добавляет переданное в запросе имя к строке \l)osDei4ces\UNC, после
чего вызывает для открытия файла диспетчер ввода-вывода. Указанная строка
является именем символической связи, которая разрешается в \pevice\\1ul> —
объекте-устройстве, представляющем драйвер МНР, как показано на рис. 9-12.
Драйвер МНР принимает данный запрос и асинхронно посылает IRP каж-
дому зарегистрированному редиректору. Затем он ждет, пока какой-нибудь из
них не распознает имя ресурса и не ответит. Когда редиректор распознает имя,
он указывает, какая часть имени для него уникальна. Например, если именем
является строка \\f lEIJ-:N(\l413I.IC\i)iside\sc(>(>l>Jd<>c, то редиректор Windows NT рас-
познает и обгтявляег своей подстроку' \\HELENC\PUBL/C. Драйвер МНР кэширует эту'
информацию и впоследствии посылает имена, начинающиеся с данной подстро-
НОВЫ WINDOWS NT
Рис. 9-12. Разрешение имени UNC.
ки, сразу редиректору Windows NT, i iponyc кая стадию “ощхюа”. Кэш драйвера лц•
обладает средством тайм-аута, так что если строка не используется в течет ie i ick*.-
торого периода времени, то ее связь с данным |юднрекгором удаляется.
Если более одного редиректора признает ресурс своим, то МНР обращц
ется к списку редиректоров в копфшурационном реестре, чтобы определив
какой из них имеет приоритет. 11орядок записей в списке редиректоров можц
изменить путем редактирования базы данных реестра.
.3.2 Транспортные протоколы
После того, как сетевой запрею достигнет редиректора, он должен бы ть <п *
правлен по сети. За последние десять лет появилось много различных прочь
колов для передачи информации по сети. Система Windows NT нс предост®
лист все протоколы. но должна по меньшей мере допускать их добавление"
будущем. И чем легче будет это сделать, тем лучше.
В Windows NT протоколы транспортов реализованы как драйверы, кот*
рыс, подобно редиректорам и серверам, мелут динамически загружаться и ни
гружаться. В традиционной селевой модели редиректор, использующий некоТ"
рый транспортный протокол, должен знать входной формат, ожидаемый драй
вером протокола, и посылать ему запросы именно в данном формате. Ни<кк|К
уровни редиректора требуется переписать, чтобы обеспечить поддержку ,чрУ|1!'
механизмов передачи данных для каждого используемого транспорча.
Windows NT устраняет эту проблему, предоставляя для редиректоре1’’1
других сетевых драйверов верхнего уровня единый программный иитерфе111
называемый интерфейсам драйвера транспорта (transport driver intcrfac1
TDI). TDl обеспечивает независимость редиректоров и серверов от испо.'П>!Уг
мых ими транспортов. Таким образом, одна версия редиректора пли сервер
можег использовать механизмы всех доступных транспортов (см. рис. 9 I1'
TDI - это асинхронный, не зависящий от транспорта интерфейс, реа:|"
зующий общий механизм адресации и разнообразные сервисы и библиочсТ'11
Все драйверы транспорта предоставляют этот интерфейс на самом верхн1'1
уровне, чтобы редиректоры (и серверы на удаленных машинах Windows
могли вызывать его, независимо от того, какой транспорт располагается i"1’
ннтерс(х.т1сом. Чтобы послать запрос, диспетчер ввода-вывода вызывает рсД,г
Глава 9. Сеть
Пользовательский
режим
Режим ядра
Интерфейс драйвера транспорта (TDI)
STREAMS
£
NetBEUI TCP/IP IPX/SPX DECnet
i-----11-------1--------
I i
I Интерфейс NDIS
I I
Драйверы сетевых плат
"— >/<сети
Рис. 9-13. Интерфейс драйвера транспорта (TDI).
ректор, передавая ему IRP для обработки. Встроенный редиректор обрабатывает
запрос, посылая SMB по виртуальному контуру на удаленный сервер. Другие ре-
директоры могут использовать иные способы взаимодействия с серверами.
TDI предоставляет набор функций, которые редиректоры используют
для посылки любых данных средствами транспорта. П Л поддерживает переда-
чу как с установлением постоянного сеанса (виртуальная цепь), так и без него
(датаграммы). LAN Manager использует коммуникации с установлением сеанса,
тогда как IPX фирмы Novell является примером сети, осуществляющей связь без
постоянною сеанса. Microsoft исходно предоставляет следующие транспорты:
Транспорт NetBEUI (NetBIOS Extended User Interface transport) —
транспортный протокол локальной сети, созданный IBM для работы
под сетевым интерфейсом NetBIOS фирмы Microsoft.
я Транспорт TCP/IP (Transmission Control Protocol/Intcrnet Protocol
transport). Этот протокол был разработан для Министерства обороны
США и предназначен для соединения разнородных систем че|Х‘з гло-
1
бальные сети. TCP/IP широко распространен в сетях UNIX и позволяв
Windows NT взаимодействовать с различными сервисами на UNIX-m;i
шипах. Транспорт TCP/IP работает в среде, совместимой со STKEAAJS
Среди прочих существующих или разрабатываемых Microsoft и другим,,
фирмами транспортов* можно назвать:
I» IPX/SPX (Internet Packet Exchange/Sequenced Packet Exchange) — I|;1
бор транспортных протоколов, используемый программным обеспече-
нием NetWare фирмы Novell Corporation.
® Транспорт DECnet — собственный протокол, используемый Digital Equip,
ment Corporation, которые предоставляется для связи систем Windows '
NT с сетями DECnet.
• AppleTalk. Это протокол, разработанный Apple Computer, Inc., который
позволяет системам Windows NT взаимодействовать с компьютерами •
Apple Macintosh. >
Транспорт XNS (Xerox Network Systems) — это транспортный прото-
кол, разработанный Xerox Corporation и использовавшийся в первых
сетях Ethernet.
Среда STREAMS заслуживает более подробного обсуждения. Это среда раз-
работки драйверов на UNIX System V, которая обеспечивает драйверам транс-
портов высокую степень переноси мости между разными ОС. Среда STREAMS ।
(которая отображается в TDI на своей верхней границе, а в NDIS 3.0 на нижней)
позволяет добавлять в Windows NT большое количество ранее разработанных
для этой среды драйверов лишь с незначительными модификациями или вовсе
без изменений. Драйверы транспортов, такие как IPX\SPX, DECnet и другое, мо-
гут быть реализованы либо как STREAMS—совместимые, либо как монолитные i
драйверы (типа NetBEUI).
9.3.3 Среда NDIS для сетевых драйверов !
Описанные в предыдущем разделе драйверы протоколов не обращаются к сети
nenocjx-дственно. Подключение компью тера к сети обеспечивается сетевой т ma- !
той или микросхемой, либо встроенной, либо вставляемой в гнездо раевп тре-
ния. Каждая сетевая плата (называемая иногда сетевым адаптером) способна ра-
ботать с определенным типом кабеля и в сети определенной топологии* 5.
Сетевые платы поставляются вместе с сетевыми драйверами, которые в про-
шлом часто реализовывали определенный сетевой протокол — например, XNS ,
или TCP/IP. Windows NT допускает' одновременную загрузку нескольких драйве"
ров для разных протоколов-, но было бы далеко не лучшим решением, если бы
* Современные версии Windows NT поддерживав >т протоколы 1PX/SPX и AppleTalk.
5 Здесь подразумевается использование сетей старого типа, соединяемых при помощи кабелей или
возможно, телефонных линий- Однако в современное сетевое оборудование входят также высоко
технологичные средства передачи данных, такие как оптоволоконные кабели, спугнпковая связь и
микроволн' эвые пе|х?датчнкн.
|
i/uudvi у. r—o t
Рис. 9-14. Интерфейс NDIS 3.0.
каждый изготовитель сетевых плат гкдтеписывал свои драйверы для поддержит
нескольких протоколов. Чтобы помочь независимым производителям избсжатт
лишней работы, Windows NT предоставляет инт ерфейс и среду, называемую сне
цификацией интерфейса сетевого драйвера (network driver interface spccifica
tion, NDIS), которые изолируют сетевые драйверы от особенностей различны?
сетевых протоколов и наоборот (это иллюстрирует рис. 9-14).
Вместо того, чтобы писать для Windows NT транспорто—зависимые драй
веры, производители сетевого оборудования реализуют интерфейс NDIS на са
мом верхнем уровне одного драйвера. Это позволяет любому драйверу прото
кола работать с данной сетевой платой, вызывая функции этого интерфейса
Таким образом, пользователь может работать и ио cent TCP/IP, и по сстт
NetBEUI (или DECnet, NetWare, VINES и т. д.) при помощи одной сетевой плать
и одного сетевого драйвера.
Интерфейс NDIS присутствовал и в IAN Manager, по для Windows NT был:
разработана новая версия ND1S 3.0". Эта версия является переносимой (паппса
на на С), модернизирована для использования 32-разрядпых адресов вместе
16—разрядных и многопроцессорных компьютеров. Как н предыдущие версии
она поддерживает несколько независимых сетевых соединений и несколько од
повременно загруженных транспортных протоколов.
Bqx Hii NDIS 1.0 и 2.<> были совмесню разработаны TCom corporation u Microsoft
Каждый драйвер NDIS отвечает за посылку и прием пакетов по сети и
управление сетевоп пла той. В своем нижнем слое он работает непосредствен^
с обслуживаемой им платой или платами, используя для доступа к ним ироцедх
рг>1 ND1S. Драйвер NDIS запускает операции ввода-вывода на сетевой плат-- (|
получает от нес прерывания. Он вызывает расположенные над ним драйвер,,
протоколов, чтобы сообщить о получении данных пли уведомить о завершена-.
1 передачи iвходящих да! п 1ых.
Благодаря NDIS сетевые драйверы переносимы и не содержат И1к’юр.1а
ции о процессоре пли ОС, с которыми работают. Сетевые драйверы вылып.|!Г11
процедуры NDIS, чтобы изолировать себя от особенностей аппаратной над.
формы, поэтому их можно легко переносить с одной системы Windows N'T
другую или 1 ia будущие системы MS-DOS\ Windows. Ji Windows NT програ ммцО(.
обеспечение NDIS вызывает функции ядра NT для получения и освобождение
спин-блокировок (чтобы сделать безопасной работу в многопроцессорной
среде ), а также обращается к гтроцедурам диспетчера ввода-вывода для iюдюпо-
чсния объектов—п[эерывапий к нужным IRQL в таблице распределения ядра. Это
лишь два примера задач, которые сетевому драйверу пришлось бы выполнять
самостоятельно, если бы он был написан как обычный драйвер NT. Вызывая
вместо этого процедуры NDIS, драйверы NDIS, написанные для Windows N'[.
легко переносятся в среду драйверов виртуальных устройств Windows.
Среда распределенных приложений
В противоположность своему определению вычислительной сети, [Эндрю Та-
ненбаум определяет распределенную систему как такую, в которой “существова-
ние нескольких автономных компьютеров является прозрачным (т. е. невиди-
мым) для пользователя”7. Иными словами, одна ОС управляет несколькими сете-
выми компьютерами и планирует время их процессоров. Windows NT не являет-
ся распределенной ОС. Она можег работать на многопроцессорном компьюте-
ре, планируя загрузку’ всех процессоров, по требует от последних использова-
ния общей памя ти.
Несмотря I ia то, что Windows NT i ie является распределит и юй ОС, она пре-
доставляет средства для создания и выполнения распределенных приложений.
Когда-то распределенная обработка означала, что пользователь может выпол-
нять печать с нескольких компьютеров, посылая задания на печать удаленному
серверу- печати. Аналогично, часто целый компьютер исполыювался просто как
хранилище совместно используемых файлов, которые пользователь мог копи-
ровать па локальные машины для обработки. Теперь распределенная обработка
стала более совершенной. Вместо того, чтобы хранить большие файлы базы дан-
ных на удаленной машине и копировать их на локальную всякий раз, когда
пользователь захочет обратится к базе, приложения типа Microsoft SQL Server
дают возможность отправите запрос, который обрабатывается путем выползicihi»
операций поиска н сорптровкп на удаленной машине. Когда обработка закапчи-
вается, на машину' пользователя пересылаются только результаты запроса. Кли-
ент-серверные вычисления такого типа снижают нагрузку'на самую малопроиз-
водптслыгую часть системы — сеть — и перекладывают раооту на удаленный про-
цессор, освобождая локальный. Пренмущеспю подобных приложении в том, что
они расширяют вычислительные возможности однопользовательски!! рабочей
станции, используя процессор удаленного компьютера, часто более мощного.
Вычисления такого типа расширяют клиент-серверную модель, описан
ную в гл. 5, где клиент посылает запрос па исполнение серверному процессу
Отличие состоит в том, что серверный процесс исполняется па другон машине.
В локальной клиент—серверной модели Windows NT два процесса используют
для пересылки информации между своими адресными пространствами сред-
ство передачи сообщений, называемое локальным вызовом процедур (LPC). Для
распределенной обработки необходимо средство передачи сообщений более
общего характера. < )но не должно делать предположений о том, какому процес-
су будет постилаться сообщение п па каком компьютере он исполняется. Кроме
-того, в связи с большой вероятностью отсутст вия памяти, общей для клиентско-
го и серверного процесса (если только не случилось так, что они выполняются
на одном и том же компьютере), такое средство передачи сообщений должно
предполагать, что все данные будут копироваться из одного адресного про-
странства в другое по сети.
Клиент-серверные вычисления представляют собой подход прилсякений
(а не ОС) к реализации распределен!юй обработки, однако они нс могут успеш-
I. но выполняться без i вдлежащей поддержки со стороны ОС. Для успели к >й реа-
лизации клиент—серверных вычислений ОС должна предоставлять:
способ создания и исполнения частей приложения как на локальных,
так и на удаленных компьютерах;
механизмы уровня приложений для передачи информации между ло-
кальными и удаленными процессами;
• поддержку сет и, включая средства транспорт а.
Большая част ь этой главы была посвящена обсуждению третьего пункта. В
следующих подразделах рассматриваются два первых.
9.4.1 Удаленный вызов процедур8
Средство удаленного вызова процедур (remote procedure call, RPC) позволяет1
создавать приложен тя, состоящие из произвольного числа процедур, из которых
часть выполняется локально, а часть — по сети на удаленных компьютерах. RPC
предоставляет модель работы с сетью, ориентированную на процедуры, а не на
транспорты, что позволяет упростить разработку распределенных приложений.
Сетевое программное обеспечение традиционно основывается на модели
ввода—вывода. В Windows NT, например, сетевая операция начинается с т ого,что
приложение выдаст запрос удаленного ввода-вывода. ОС обрабат ывает запрос,
передавая его редиректору, который выступает в качестве удаленной файловой
системы. После того как удаленная система от работает запрос и вернет резуль-
Andrcw S. Ttincrilxium, Computer .Networks. 2d «I. (T.nglewood Clifts, N.J.: Prentice tLill 1989) 2
R Часть информации данного раздела схзювываегся на материалах из руководства Microsoft Remote
Procedure Call Ib^umnier's Guide and Rcp icuce, фрагменты к<ую|7ок> лицензированы у Digital
Equipment Corporation. Для Microsoft эпи документ был переработан Джоном Мюрреем (John
Murray). Рисунки в этом разделе подготовлены сотрудником Microsoft Полом Личем (Paul Ijeach).
НОВЫ WINDOWS NT
таты, сетевая плата rei юрирусг прерывание. Ядро обрабатывает это прерывание,
и исходная операция ввода-вывода завершается, возвращая результаты вызыва-
ющей программе.
RFC исполкзуст совершенно другой подход. Приложи шя RFC выглядят так
же, как и другие структурные приложения, — у них есть главная программа, ко-
торая для выполнения специфических задач вызывает процедуры или библио-
теки процедур, как показано на рис. 9-15.
Однако отличие между приложениями RFC и обычными программами со-
стоит в том, что некоторые библиотеки процедур в приложении RFC выполня-
ются па удаленных компьютерах, а другие — локально (см. рис. 9 16).
Для приложения RPC все процедуры выглядят локальными. Друт ими слова-
ми, вместо того, чтобы заставлять программиста писать код для передачи за> цхь
сов на вычисления или ввод-вывод по сети, для работы с сетевыми протокола-
ми, обработ ки сетевых ошибок, ожидания результатов ит. д., программное обес-
печение RFC выполняет эти задачи автоматически. А средст во RPC Windows NT
может работать с любыми доступными протоколами, загруженными в систему.
Для написания приложения RFC программист решает, какие процедуры
будут исполняться локально, а какие — удаленно. Например, предположим, что
обычная рабочая станция подключена по сети к суперкомпьютеру ('RAY или к
машине, специально предназначенной для быстрого выполнения векторных
вычислений. Если программист пишет программу, работающую с большим*1
матрицами, то с точки зрения производительности имеет смысл переложить
математические вычисления на удаленный компьютер, написав программ} 13
виде приложения RFC.
Функционирует приложение RFC следующим образом. В процессе своей
работы оно вызывает как локальные процедуры, т ак и процедуры, отсутст вую-
щие на локальной машине. Для обработки последнего случая приложение свя-
зывается с локальной DLL, которая содержит' по одной нроцеду1>е-заглуН1ке
(Stub procedure) для калетой из удаленных процедур. Процедура-заглушка имес'1
тоже имя и интерфейс, что и удаленная процедура, но вместо выполнения соот-
ветствующей операции заглушка берет переданные ей параметры и выполняет
их преобразоаепте (marshaling) для передачи по сети. Преобразование парам»'1’'
ров это упорядочение1 п упаковка их в определенном (]хтрматс, пригодном Д|И
пересылки ио сети, например, разрешение ссылок и копирование всех структур
/Ынных, па которые ссылаются указатели.
Сеть
Рис. 9-16. Приложение RPC, использующее библиотеки.
* атсм заглушка вызывает процедуры библиотеки RFC периода выполне-
1 »1я, и они находят компьютер, i га котором расположены удалет тные процедуры,
определяют используемые этим компьютером механизмы транспорта и посыла-
ют запрос при помощи локалы того программного обеспечения сетевою траттс-
порта. Когда удаленный сервер получает запрос RFC, он выполняет обратное
преооразоваиие парамет ров, реконструирует оригинальный вызов процедуры и
ызываст ее. По окончании работы сервер выполняет ехбратную последователь-
ность действий ;щя возврата результатов вызывающей программе Библиотека
периода выполнения показана па рис. 9-17.
Кроме опблпотеки периода выполнения, всостав cpc'icrn RPC Microsoft вхо-
дит компилятор - так т тазываемый компилятор .MIDI (Microsoft Interface Definition
М1™;~ЯЗЬ,КОП1,С:11"»' интерфейса фирмы Microsoft). Использование
компилятора MIDL упрощает- написание приложений RPC Программист пишет
набор обычных прототипов функций (в предположении, что это язык С или
C++), описывающих удаленные процедуры. Затем он добавляет к этим щютотн-
пам некоторую допещнительную и, .формацию, например уникальный для сети
идентификатор пакета процедур и номер версии, плюс атрибуты, указывакЧ| |
является ли параметр процедуры входом, выходом или и тем и другим. 11:;
модифицированных прототипов и состоит файл т\ языке опис ания шпне/
са (interface definition language, IDL).
После создания файла IDL он транслируется компилятором MIDL, K,fj
рыи создает п|х,цсдуры-заглуш кидая клиентской и серверной стороны, а |;1г'
заголовочные файлы для подключения к приложению. При компоновке клцС|'
ского приложения с файлом процедур-заглушек разрешаются все ссылю/1
удаленные процедуры. Затем, используя аналогичный процесс, удаленные
цедуры устанавливаются па удаленной машине. Программисту, желающему -10 *
ко вызывать существующее* приложение RPC, нужно лишь написать прогр;П|/
для клиентской част и скомпоновать ее с локальной библиотекой R1>C перц(,,'
выполнения.
Библиотека RPC периода выполнения использует для взаимодействия
транспортным протоколом единый интерфейс с\>сшуна к транспорту
Клиентская машина
Сеть
Клиентская Клиентская Клиентская
заглушка 1 заглушка 2 заглушка 3
Библиотека RPC периода выполнения
Библиотека RPC периода выполнения
Серверная
заглушка 2
Библиотека
3
Библиотека
2
Библиотека
1
Сервер 1
Сервер 2
Рис. 9-17. Библиотека RPC периода выполнения.
Приложение
Библиотека RPC периода выполнения
Серверная
заглушка 1
Серверная
заглушка 3
(RIX', transport provider interface). Этот интерфейс служит тонкой прослойкой
между средством RFC п транспортом, которая отображает операции RI’C в фун-
кции, предоставляемые транспортом. Средство RFC для Windows NT предостав-
ляет DLL компонентов доступа к транспорту для именованных каналов, NetBIOS,
TPC/1F и DECnet. Поддержку других т ранспортов можно ввести, написав допол-
нительные DLL. Таким же образом средство RI’C поддерживает работу с различ-
ными сетевыми средствами защиты. Кроме DLL компонентов доступа к транс-
порту, между средством RFC', и сетью могут быть добавлы 1ы DLL Защ1ггы. В отсут-
ствие других DLL защиты щюграммное обеспечение RPC для Windows NT ис-
полынет встроенную защиту именованных каналов (именованные каналы под-
робно обсуждаются в разд. 9.4.2).
Для того, чтобы средство RFC могло взаимодействовать с приложениями
RFC' на другой машине, они должны нсполкювать одни и те же соглашения RFC..
Microsoft RPC соответствует craiщарту RPC, установлен! к>му Open Software Foun-
dation (OSF) в спецификации среды распределенных вычислений (DCE). Таким
образом, приложения, написанные с использованием Microsoft RI’C ', могут вызы-
вать удаленные процедуры на других системах, использующих стандарт DCE.
Большинство сетевых сервисов Windows NT являются приложениями RI’C,
а это значит, что они могут вызывайся как локальными процессами, так и про-
цессами на удаленных машинах. Таким образом, удаленный клиент ский компь-
ютер может обращат ься к сервисам Вашего сервера для просмотра списка со-
вместно используемых ресурсов, открытых файлов, очередей печати или актив-
ных пол кюват елей на этом сервере, либо он может вызнать сервис сообщений
для посылки Вам сообщения (конечно, при наличии соответствующих прав дос-
тупа). Чак Лет щмайер (Chuck Lenzmeier), разработчик сервера Windows NT. счита-
ет сервисы, работающие по RPC, од1 юй из наиболее заслуживающих упомина-
ния и полезных особенностей сетевой поддержки Windows NT.
Именованные каналы
Первоначалы ю именованные каналы (named pipes) разрабатывались Microsoft в
качестве интерфейса высокого уровня к NetBIOS. NetBIOS выполняет для сете-
вых приложений ту же функцию, что и BIOS для MS-DOS — абстрагирует их от
оборудования. Таким образом, он является низкоуровневым средством сетевых
коммуникаций. Именован! 1ые каналы предоставляют более абстрактный (и удоб-
ный) селевой интерфейс. Вместо того, чтобы иметь дело с маршрутизацией, пере-
сылкой да! и 1ых и т. д., пре >граммисг. использующий имиюванг!ые каналы, может
прост открыть канал и поместить в него данные. Пользователь именован! юго
канала открывает ег о и считывает данные. Передача данных между компьютера-
ми выполняется автоматически, и один вызов именованного канала эквивален-
тен нескольким операциям на уровне транспорта.
В Windows NT именованные каналы реализованы в виде драйвера файло-
вой системы именованных каналов — псевдофайловой системы, хранящей дан
ные капала в памяти и выдающей их по запросу. При обработке локального за-
проса к именованному каналу и при приеме запроса к нему- от удаленного ком-
пьютера она работает как обычная файловая система.
Когда процесс использует именованный канал с именем UNC (с сетевым
именем), обработка выполняется так же, как и для других запросов к удаленным
“файлам”. Запрос перехватывается драйвером MIJP и направляется редиректору,
отвечающему за данную сеть. Схема обработки запросов к локальным и удалц,
ным именованным каналам показана на рис. 9—18.
Подобно файлам, именованные каналы представлены в Windows N'l
левыми объектами и работают под управлением тех же механизме >в защиты,
и другие объекты исполнительной системы NT. Когда локальный поток пыт-^1
ся открыть именованный канал, запрашиваемые потоком права доступа П]х)11(;
ряются в соответствии с ACL, связанным с файловым объектом именованно^
канала. Если запрашиваемые права не совпадают с данными ACL, то доступ Зз
рещается. Следователь! их средство именова! шых кат гал< >в содержит ветрехл цП1(
защиту. Кроме т ого, оно позволяет одному процессу принимат ь на себя атриё/
ты защиты другого процесса. Такая возможность называется нмперсонацщ*
(impersonation), 01 ia позволяе т, например, подсистеме выступать в образе кл 1icny
ского процесса при открытии удаленного именованного канала.
Поскольку именованные каналы могут располагаться как на локальных, так
и па удаленных машинах, они предоставляют средства коммуникации и совме-
сотого использования данных для клиентских и серверных процессов распре,
деленного приложения. Такое средство коммуника! (ИИ между процессам! i скрц.
вает от приложения межмашит iyio передачу данных. Под слоем своего API име-
нованные каналы исполотуют для передачи данных один из транспорт!» ниж-
----->/<сетК
Рис. 9-18. Робота именованных каналов на клиентской стороне.
Ю6
него уровня. В отличие от RFC, именованные каналы реализуют модель ввода-
вывода и удобны /утя передачи по токов данных между процессами.
Средство RFC может работать поверх большого количества транш юртов,
используя механизмы защиты разных типов. Однако при работе по септ LAN
Manager средство RPC использует в качестве сетевого транспорта именованные
каналы. Благодаря этому RPC может воспользоваться встроенными механизма-
ми защиты, которые Windows NT применяет к именованным каналам.
Корпоративные сети и распределенная защита
Стандартная сист ема Windows NT пост является со встроенными в нее возмож-
ностями сервера. Сервер обеспечивает выполнение операций рабочих групп,
таких как копирование файлов с одной машины на другую или подготовка
принтера для совместного использования в сети. Подобная прост ая сетевая под-
держка полезна для небольших фирм, домашних сетей или отдельных рабочих
станций, подключающихся к сет и по телефонным линиям. Однако в больших орга-
низациях и учреждениях могут понадобиться дополни тельные возможности.
В предыдущих главах этой книги были описаны различные аспекты защи-
ты в Windows NT. Контроль доступа — это важная част ь любой сетевой опера-
ции, необходимая для защиты данных одного пользователя от других пользона-
телей, служебной информации фирмы от посторонних пт д. Однако с защитой
связан определенный объем администрирования. Например, в г/г. 5, “Windows и
защищенные подсистемы”, был описан обязательный процесс регистрации
пользова т еля в системе гг аутентификации системой той информации, которая
была введена во время регистрации. Для того, чтобы ОС распознавала пользова-
теля, администратор должен создать для него учетную запись в топ системе, с
которой пользователь желает- работать. Windows NT хранит идентификаторы п
пароли пользователей в так называемой базе данных диспетчера учетных за-
писей [security accounts manager (SAM) database].
Когда пользователь пытается зарегистрироваться на своей рабочей стан-
ции, Windows NT просматривает базу данных SAM, связанную с этой рабочей
станцией, и проверяет пароль. В небольших сетях каждый пользователь работа-
ет на некоторой рабочей ст анции Windows NT, и каждая рабочая станция имеет
собственную базу учетных записей, как показано на рис. 9 19.
Сеть
Робочоя станция 1 SAM 1 Робочоя станция 2 SAM 2 Рабочоя станция 3 SAM 3
Рис. 9-19. Конфигурация сети малого размера.
Если пользователю требуется доступ к ресурсам всех рабочих станций
на каждой из них у него должна быть отдельная учетная запись. На практике
означает, что сели пользователь изменил сноп пароль, но хочет, чтобы гоз (у, ’
одинаковым на всех машинах, с которыми он работает, ему необходимо обц,'
вить пароль для каждой машины но отдельности.
Такой способ сопровождения совершенно нс годится для больших кош,,
ратпвных сетей. С возрастанием числа рабочих станций объем их адмипистр|(
ровапия будет расти пропорционально. Для удовлетворения нот|х.биостеи ц|М)
мышленных сетей Клифф Ван Дайк (Cliff Van Dyke). Джи м Келли (Jim Kelly) u
Джим Хорн (Jim Horne) разработали расширения встроенной сетевой поддерг
кн Windows NT. Это программное обеспечение, предварительно названное |
Manager for Windows NT", добавляет новые возможности к поддержке одиоран.
новой сети, имеющейся в рабочей станции Windows NT’. Оно позволит созда.
Рис. 9-20. Конфигурация сети среднего размера.
Microsoft выпускает Windows NT в двух вариантах. рабочая станция (Windows NT Workstation) ••
сервер (Windows NT Server). Последний как раз и ссутержпт упомянутые продвинутые возможна п1
Первоначально он назывался Windows NT Advanced Server. (Прим, псрсв.)
° На момент выхода .чтой книги в печать Microsoft планирует выпускать данный продукт отдельно °*
ОС. Он предпешожичельпо будет предоставлять продвинутые сетевые вскшожности, описываемые
ниже в данном разделе.
кгп> сетевые домены (network domains), более примитивная версия которых су
шс< твуст в LAN Manager 2.x, для упрощения задач администрирования. Про-
стой сетевой домен показан на рис. 9—21).
11а рисунке в большом овале показан сетевой домен, в который объедине-
ны все компьютеры. В домен входят несколько рабочих станции и несколько
серверов; последние называются коитрогчерамн домена (domain controllers).
При подключении к системе пользователь выбирает подключение либо в соот-
ветствии с учетной записью, определенной на его собст венной рабочей стан-
ции, либо в соелвстствнн с учетной записью, находящейся в его не]>вичнсм <)о-
мене (primary domain), т. с. в домене, к которому принадлежит его машина.
Если используется учетная запись локальной машины, то локальное про-
граммное обеспечение аутентификации использует для проверки параметров
подключи иля информацию из базы дагиных SAM рабочей статmiin. Есш i же пользо
ватель регистрируется в домене, локальное программное обеспечение аутенти-
фикации посылает парамстры {тегист рации для проверки в домен. На первич-
ном контроллере домена находится база данных SAM, общая для всего домена, а
резервные контроллеры домена хранят ее реплицированные копии. Благодаря
этому пользователю не требуется отдельная учетная запись на каждом сервере,
а кроме того, повышается отказоустойчивость. При выключении одного из кон-
троллеров домена система автоматически может перенаправить запрос на реги-
страцию другому серверу.
На рис. 9-20 линия между рабочей станцией и первичным контроллером
домена показывает отношение доверия (trust relationship) — это термин из об-
ласти контроля прав доступа, обозначающий, что рабочая ст анция “доверяет"
домену проверку законности регистрации пользователя. Отноше! ше доверия
позволяет Windows NT установит!, безопасный канал между двумя сист емами и
обеспечить доступ к (тесу^кам домена.
Дополнительный эффект от организации компьютеров в домен состоит в
том, что пользователь можег заретистрироватыгя в домене с любой входящей в
него рабочей станции или сервера и работать со своей рабочей ст анцией уда-
ленно. Например, если некоторая группа организовала при помощи систем
Windows NT, объединенных в домен, лабораторию разработки или тестирова-
ния, то пользователь, имеющий в дагп юм домене учетную запись, м< >жет зареги-
стрироваться под своим идентификатором с любой машины в лаборатории.
Возможност ь создания доменов полезна для сетей среднего размера, где
несколько серверов обслуживают большое количество рабочих станций. В зна-
чительно более крупных сетях, таких как сети корпораций, значение доменов
возрастает еще больше, с их помощью компания может разделит ь свои ресурсы
на несколько дискретных порций (доменов) и гибко управлять ими. Конфшура-
ция большой сет показана па рис. 9-21.
Изображенная па рисунке сеть содержит три домена.- два для групп разра-
ботчиков (TEAMl и ТЕАМ2) и один для административного состава (OPERA-
TIONS). Отношение доверия доменов (trusted domain relationship) имеет место
как между’ обоими доменами разработчиков, гак и между доменами разработ -
чиков и доменом администрации. Такая структура позволяет, например, разра-
ботчику из ТЕАМ1 регистрироваткя в своем первичном домене с машины из
домена ТЕАМ2. Болес интересно, однако, то, что такая структура обеспечивает
члену административной группы, зарегистрировавшемуся с помощью своей
обычной учет ной записи пользователя, прозрачный доступ к ресурсам обоих
Рис. 9-21. Конфигурация большой сети.
доменов ТЕАМ1 и ТЕЛМ2, как если бы эти ресурсы принадлежали домену
OPERATIONS. Предыдущие продукты LAN Manager требовали, чтобы у адмнпн-
ораторов были отдельные учетные записи во всех доменах, которые они дол-
жны администрировать, однако в LAN Manager for Windows NT это требование
снято. В данном примере системный администратор, зарегистрировавшись,
получает доступ к ресурсам в других доменах. Когда он обращается к домену
ТЕАМ1, программное обеспечение защиты этого домена проверяет наличие
отношения доверия с доменом OPERATIONS. Такое отношение существует,
поэтому домен TEAM ! использует защищенный канал для посылки неявного
запроса па регистрацию домену OPERATIONS, который аутентифицируй
пользователя, обращаясь к своей базе данных SAM. В случае успешной
аутентификации системный администратор может устанавливать программных
обеспечение, выполнять резервное копирование и другие действия по С'ШрО"
вождению. Распределенная защита такого тина позволяет даже очень крУ11'
пым организациям с большим количеством доменов легко управлять своим11
ресурсами и в то же время обеспечивать доступ к сетевым ресурсам из люб0'
го места сети.
Хотя большие н средине сетевые конфигурации обеспечивают пользова-
телям гибкий доступ к ресурсам, каж,тын пользователь может ограничить .дос О11
к своей машине следующими способами:
И назначая файлам или другим локальным ресурсам списки контроля
доступа (ACL), которые разрешают или запрещают доступ отдельным
пользователям или группам пользователей;
назначая (или не назначая) привилегии отдельным пользователям или
группам;
* явным образом определив для пользователей или групп один или не-
сколько разрешенных способов регистрации, таких как:
О интерактивный (регистрация при помощи клавиатуры);
□ сетевой (регистрация по сетевому соединению);
□ сервисный (регистрация как сервис, i гапример, сервис сообщений
или сервис оповещения).
Запрещая отдельным пользователям или группам использовать привиле-
гии, назначая ACT локальным объектам и ограничивая список пользователей,
которые могут подключаться к данной рабочей станции, полыюватель может
управлять своей средой. Если пользователь пожелает, то он может по любой
причине запретить доступ к своей машине всем, кроме себя. Благодаря по-
добному разнообразию возможностей разработчики иногда называют про-
граммное обеспечение администрирования Windows NT “FlexAdmin” (Flex от
flexible—“гибкий”).
В дополнение к доменам, доверяемым доменам и распределенной защите
LAN Manager for Windows NT предоставляет зеркализацию дисков и чередование
дисков, повышающие отказоустойчивость, а также тиражирование файлов и гра-
фические средства администрирования сервера.
Заключение
Широкое распространение больших компьютерных сетей и потребность пользо-
вателей во взаимодействии и совместном использова! ши цеитрализоват тых баз
данных привели к тому, что сетевое програмлшое обеспечение из разряда по-
лезного перешло в разряд необходимого. Подключившись к одгюй или i юсколь-
ким сетям, ОС может повысить свои вычислительные .мощности и возможности
доступа к данным, разрешить поЛ1>зователям взаимодействовать и совместно
использоват ь данные, а т акже предоставит ь приложениям т акие возможности,
кот орые отдельно взятая ОС не смогла бы обеспечить. Чтобы все перечисленное
было реализоваг ю эффект ивно, сетевое программ! юе обеспечст me Windows NT
встроено в ОС и работает на равных правах с остальными частями исполни-
тельной сис1емы NT. Хотя сетевая поддержка и встроена, oiia не “зашита” жестко
в систему. Поддерживаемые в Windows NT гибкие модели DLL и ввода-вывода
позволяют динамически добавлять и удалять сетевое программное обеспечение
из системы.
Windows NT предоставляет несколько сетевых hi п•ерфейсов, которые
дают ей возможность подключаться к различным типам сетей и взаимодейство-
вать с разными типами вычислительных систем. Интерфейс сетевого доступа
позволяет независимым производителям сетей подключат ься к Win32 API про-
смотра сетевых ресурсов и ввода-вывода; слой LDI позволяет сетевым редирек-
торам и серверам использовать все доступные драйверы транспортов без м0. I
фикацни собственного кода; наконец, слой NDIS дает драйверам трапсц()^'
возможноеть работа й, с сетевыми платами любых производителен и обссгд^'
васт переносимость драйверов с систем Windows NT в среду драйверов вцр|,
альных устройств Windows.
Средства для распределенных приложений, включая RPC и механизм
коммуникаций между процессами, позволяют разраболчикам приложений п< '
нее использовать сетевые компьклеры, перекладывая на другие машины задац*
требующие большого объема вычислений, и работая с удаленными ресу|х.а411
как с локальны ми. Кроме того, продукт LAN Manager for Windows NT расширь
сетевые возможности ст андартной системы Windows NT, чтобы они отвечав
потребностям больших корпоративных сетей в распределенной защите и q*.,’
ствах администрирования. Благодаря своим широким сетевым возможносцу
Windows NT может превратить простой настольный персональный компыщ^
в расширяющуюся ест ь вычислительных ресурсов.
эпилог
"XK^indows NT разрабатывалась как расширяемая ОС, способная развиваться как
целое, путем помодульных изменений. И действительно, она уже начала эволю-
ционировать в направлениях, нс сраженных в данной книге.
Например, упомянутый лишь кратко диспетчер конфигурации (configu-
ration manager) устраняет необходимость использования AUTOEXEC.BAT,
CONFIG.SYS и различных 1NI файлов, которые пользователи так привыкли ви-
деть, исследовать, а иногда и портить. Разработанный в основном Брананом
Уитманом (Bryan Willman) и Кейтом Логаном (Keith Logan), диспетчер конфи
гурацин состоит из нескольких компонентов, важнейшим из которых является
реестр конфигурации (configuration registry). В реестре хранится вся пиформа
ция об оборудовании компьютера, на котором работает ОС. об установленном
в системе программном обеспечении и пользователях.
Реестр и соотнетстпующсе программное обеспечение Иркин прежде всего
для облегчения сопровождения системы. Для этого диспетчер проверяет уст а-
новленное оборудование и определяет сто возможности в процессе запуска сис-
темы, автоматически к< и к|м irypi ipyer макенмалы к> возмс>жтюс чтicjk > компелитi-
тов*, минимизирует число вопросов к пользователю при установке системы и
храпит всю собранную информацию в реест ре, чтобы пользователю нс прихо-
дилось вводит ь одну и ту же информацию дважды. Драйверы ус тройств, прило-
жения и пользоват ели также могут помещат ь и выбирать информацию из реес-
тра, когда им это необходимо. Пользователь может просматриват ь и модифици-
ровать конфигурационную информацию при помощи графическою редактора
реестра. Информация в реестре хранится в виде оовекпихс-нарал/етров (key
objects), которые управляются средствами защит ы и другими механизмами, при
менимыми к объектам пспол!пггельной <тктемы NT. Такая архитектура позволя-
ет Windows N1 поддерживать универсальное хранилище для всей, на первый
взглвд, совершенно разнородной информации, и в то же время обеспечивать
распределенный, но защищенный доступ к ней по сети.
Важный компонент, обеспечивающий отказоустойчивость (fault tole-
rance), также присутствует в первой версии Window s NT — благодаря -тит аничес-
ким усилиям Боба Рипна (Bob Rinne) и Майка Гласса (Mike Glass). Их ехгказоустой-
чивый драйыр диска располагается между драйвером файловой системы и дис-
ковым драйвером. Как говорит Боб, он обеспечивает “защиту данных па диске
путем создания избыточных разделов”. Это означает, что раздел диска может дуб-
лироваться различными способами. чт обы при сбое диска по-прежнему остава-
лась доступна копия данных. Зеркачизация диска (disk mirroring) означает дубли
рованне раздела диска па другом диске, а если возможно, то па диске, подключен-
ном к другому контроллеру диск:!, ч тобы обеспечить сохранение данных при
сбое диска или кон троллера Чередование дисков (disk striping) это обьедпнепие
* Современная версия Windows NT инициал! 1зир\е’1 при .загрузке около 800 параметров, записанных
в pcccipe. Эти параметры определяют важнейшие характеристики системы и се поведение.
разделов одинакового размера, находящихся на разных дисках, в одигi том. Дащ^
хранящиеся на томе, распределяются па все диски, формируя виртуальную «Гу
ласть”, проходящую по всем дискам. Такая техника храпения данных повьп,^'
производительность ввода-вывода, обеспечивая параллельное выполнение ц
скольких операций ввода-вывода на одном томе. Расширенная версия че]хгд()^
ния дисков, называемая чередованием дисков с записью четности (disk stripy
with parity), обеспечивает отказоустойчивость диска. Хранение контрольной
мы для облает диска позволяет в случае сбоя одного раздела (т. е. диска) восстал
вить его информацию, применив операцию “исключающее ИЛИ” к содержим^
остальных разделов (между7 прочим, все только что описанные возможности
это лишь част ь расширенных средств управления томами Windows NT, при ц
мощи которых можно осущест влять как логическое, так и физическое конфш-ур^
рование дискового пространст в;!. Кроме поддержки отказоустойчивых диско,
средст ва управления томами позволяют объединять несмежные области наод.
ном или нескольких дисках в один логический диск.)
Отказоустойчивость дисков Windows NT в сочетании с поддержкой i(f.
темников бесперебойного питания (uninterruptible power supply, NPS), опи.
санной в гл. 8, предоставляет администраторам недорогой способ защиты ц
восстановления данных. Некоторым специализированным приложениям, 1а.
ким как программное обеспечение обработки траг вакцин, используемое в бан-
ках и других финансовых учреждениях, требуется дополнительная степень ус-
тойчивости к отказам. Такие приложения требуют полной аппаратной избы-
точности для непрерывной работы системы. Хотя эго нужно только да
наиболее ответственного программного обеспечения, значительный задел уж
имеется в Windows NT. Система ввода—вывода, например, может динамически
удалять и воссоздавать объекты—устройства для от ражения изменений в конфи
гурации системы Дополнительные возможности, которые могут потребоваться
в будущем — динамическое переназначение букв дисков на разные физические
ресурсы и переко! контурирование устройств без последующей перезагрузки
Еще одна задача, по-прежнему стоящая перед разработчиками Windows
КГ — это полная интернационализация. На ней будут сосредоточены основные
усилия разработчиков после выхода первой версии. Ставится цель иметь едины!'1
системный код для всех стран мира. Хотя исполнительная система NT и API Win32
полностью nincpi гационализированы, часть пользовательской оболочки Win32 и
некоторые системные утилит ы еще не поддерживаю! UNICODE; требуется pcaaib
зовать некоторые дополнительные средства интернационализации, а компонент
GDI подсистемы Win32 требует расширений для полной совместимости с япоп
ским и другими азиат скими языками. Некоторые из необходимых средств ш пер
национализации включают в себя API метода ввода; новую архитектуру шрифш*
поддерживающую пути поиска доя логически комбинируемых шрифтов; интстр3'
цию в архитектуру шрифтов символов, определяемых пользователем, а также рай
ширения для поддержки ввода символов нескольких алфавитов одг ювременно-
Дополнительная работа требуется для японской, китайской и корейской
версий системы. Необходимо создать шрифлы, поддерживающие эти язык*1-
кроме того, требуется редактор метода ввода для трансляции нажат ий нескедЧ’'
i
4
ких клавиш в од1и 1 символ. Также планируется совместная работа с независимы-
ми производителями, чтобы гарантировать хорошую работу Windows NT па
специализированных или нестандартных персональных компьютерах. Напри-
мер, фирма NEC успешно перенесла Windows NT на свой персональный компь-
ютер с процессором 9800. В связи с широким распространением этого (не со-
вместимого с АТ) компьют ера в Японии он является важной целевой платфор-
мой Window’s NT.
Наконец, для выполнения существующих интернациональных приложе-
ний подсистемы среди 16—битной Windows и MS-DOS должны поддерживать
двухбайтовую схему кодирования, которая традиционно используется для
представления символов японского и других азиатских языков. Среда MS-DOS
должна быть, кроме того, обратно совместима с японской версией MS-DOS;
последняя развивалась по иному пути, нежели версии для США и европейских
стран. Команда из двадцати американских и японских инженеров, возглавляе-
мая американцем Дэвидом Мак-Брандом (David McBride), предполагает выпус-
тить первый международный вариант Window's NT и Windows NT-.I (японская
версия) через шесть месяцев после выхода версии для США.
Вопросы, связан! 1ые с защитой от i iecai гкционирова! и юго доступа, рассмат -
ривались во всех главах книги — это, возможно, и правильно, учит ывая распре-
деленную природу7 защиты Window's NT Однако защита — сложный предмет, и
многое аспекты лишь упомянуты при обсуждел ши ее основных компонентов (за-
щита объектов, распределенная защита и имперсонация). Защите можно было
бы посвятить отдельную кишу.
Весьма интерес! пя направления далы гейшей работы в област и защит ы. Мо-
дель аутент ификации, кратко рассмотрен! гая в гл. 5, не только позволяет обеспе-
чить поддержку7 новых пользовательских интерфейсов. i гапример 6ai гко.матов и
устройств сканирования отпечат ков пальцев или сетчатки глаза, но и дает воз-
можность реализовать “поверх" Windows NT другие архитектуры защиты. На-
пример, в разработке находится ауте! и ификациог гный 1гакег и API для поддерж-
ки популярной модели защиты Kerberos, выдающей охранные “билеты” субьек-
там, желающим взаимодействовать или обмениват ься данными. Приложения, ис-
пользующие модель Kerberos, смогут просто вызывать функции API Kerberos (ко-
торые будут обращаться к подсистеме защиты Windows NT) и специальный
загружаемый аутент ификационный пакет Keiberos. Аналогично, в систему7 мож-
но добавить специальные модели защиты, исполкзуемые в различных областях,
например, в банковском деле.*
В гл. 3 была кратко упомянута тема расширения Windows NT для обеспече-
ния защиты уровня В2, определенного правительством США. Переход от защи-
ты уровня С2 к уровню В2 потребует модернизации объекпюй архитектуры и
справочного монитора защиты Windows NT, чтобы опи поддерживали уровни
защиты (определяющие права пользователей и их процессов как “секретные”,
“сов. секретные” и т. д.) и секции (группы пользователей, изолированные отдру-
гих групп пользователей). Должны использоваться средства принудительного
управления доступом, блокирующие доступ процессов к ресурсам процессов,
которые имеют более высокий уровень защиты или относятся к другим секциям.
•Водыцая часть этой работы уже проделана, Современная версия поддерживает большинство евро-
пейскпх языков. Существуют также специальные версии для Японии, Кореи и т д
‘ Введение защиты Kerlx-ros планируется и разрабатываемой в настоящий момент версии 5.
ОСНОВЫ WINDOWS NT
В книге почти полностью опушено описание файл» >вой системы NT (NTFS),a
также подробности архитектуры драйверов устройств, файловых систем п сете-
вых драйверов исполнительной системы NT. Что касается диспетчера кэша -
уникального компонента Windows NT, — автор также полагается в основном на
воображение пользователя. Эти темы заслуживают отдельного изложения. Вне-
шняя и внутренняя сторона подсистем среды также гораздо более сложна, чем
эго представлено в гл. 5. Каждая подсистема имеет свою структуру и филосо-
фию. Хот я основным пользовательским интерфейсом Windows NT является под-
система W in52. другие подсистемы также могут в будущем разниться в полно-
ценные среды. Я избегала описания пользовательского интерфейса Windows
NT, главным образом потому, что он “видим” и. таким образом, более понятен
пользователям системы, чем обычно “невидимые” подробности архитектуры,
которые преобладают в данной книге. Замечу тем нс менее, что утилиты
Windows XT будут, вероятно, развиваться в том же направлении, что и Disk
Manager: они приобретут пользовательский интерфейс Windows и станут менее
похожими на приложения MS-DOS.
Как переносимая ОС, Windows NT несомненно, будет мигрировать! га дру-
гие аппаратные платформы. Например. Digital Equipment Corporation занимает-
ся се переносом на свой 6 1-разрядиып процессор Alpha АХР (первоначальное
варианте с 32-разрядными адресами, как па процессорах MIPS и Intel).'
Наконец, мы все чаще и чаще слышим об обьеК! ио-ориентированной
Windows, возвещающей приход эры “информации на кончиках пальцев”, в со-
ответствии с представлениями Билла Гейтса о будущем персональных компь-
ютеров в ближайшие десятилетия. Соответствующее программное обеспече-
ние имеет “внутреннее” название Cain» и. предположительно, будет выглядеть
как набор DLL расширений Win32 на Windows NT и MS-DOS, С его помощью
будет реализована обтх?кт1ю-ориентированная среда “рабочего стола", в кото-
рой пользователь сможет создавать, просматривать, организовывать и распе-
чатывать ресурсы независимо от их типа, внутриihcto формата iuni местопо-
ложения в сети.
Я собиралась закончить эту кишу отдельной главой о будущем Windows NT
и, может быть, даже “проповедью” о будущем пользовательском интерфейсе
Однако вычислительная техника — это область первопроходцев, a Microsoft -
фирма-первопроходец, быстро реагирующая на изменения рынка. Поэ тому де-
лать здесь прогнозы — рискованное запят ые. Достаточно сказать, что Windows
NT — отличная дорога в будущее вычислительной техники, несмотря на нес се
возможные изгибы и повороты.
* Начиная c Windows NT версии 3-51 введена поддержка 1ъчгпч|х>рмы PowerPC'.
316
БИБЛИОГРАФИЯ
Ниже приведен неполный список литера гуры, прочитанной мною при под-
готовке к написанию этой книги. В этих работах изложены основы теории ОС.
а также детали реализации конкретных ОС Они помогли мне составить план
описания архитектуры W indows NT п дали фактический материал для сравне-
ния W indows NT с другими ОС. Так как в некоторых аспектах W indows NT нахо-
дится па самом переднем крас развития технологии, то на данные темы опуб-
ликовано очень мало работ, откуда я могла бы черпать информацию. или их
вообще нет.
В библиографию включены как тс работы, которые я использовала напря-
мую, так и тс, что дали мне некоторые предпосылки для написания книги. < )дна-
ко, в пей опущены проектные спецификации, представления, замечания, коды и.
самое важное, конкретные разработчики; вес это послужило основным источ-
ником информации для книги.
Так как исследования и написание книги заняли три года, некоторые из
опубликованных работ за это время устарели. Однако в процессе работы я по-
няла, что в какой-то момент нужно остановился п начать писать, поскольку
чтение может продолжаться вечно.
Операционные системы
Boykin. Joseph, and Susan J. LoVerso. “Recent Developments in Operating Systems."
Computer (May 1990): 5—b. Авторы оппсывакхг историю и перспективы ОС
всего на двух журнальных страницах, включая благодарности, ссылки, био-
графии и даже фото авторов. Замечательно.
Dasgupta, Bartha. “Tile ('lends Distributed Operating System." Computer (November
1091): 34—I I-
Kenah, Law rence J., Ruth Goldenberg, and Simon E. Bate. VMS Internals and Data
Structures: Version 4-4- Maynard, Mass.: Digital Press. 198T Некоторые разделы
W indows NT напоминают (иногда лишь издали) разделы VMS — например,
обработка исключении, асинхронный вызов процедуры, система ввода-вы-
вода, планирование потоков. Я обнаружила также, что многие выражения, в
которых разработчики Window's NT описывают исполнительную систему NT,
заимствованы из терминологии VMS. В этом нет ничего удивительного, если
учесть, что многие разрабо тчики исполнительной системы NT пришли из
фирмы DEC. (Кто-то заметил, что если прибавить 1 к каждой букве в
“UAL” — имени бестелесного компьютерного голоса в фильме 2001: A Space
Odyssey, получится “IBM’’. Известный компьютерный обозреватель Джон
Дворак (John Dvorak) также обратил внимание, что если прибавить 1 к
каждой букве в "VMS”, то получится — Вы уже догадались “WNT”, или
Windows NT. Ловко.)
317
ы WINDOWS NT
Библиография
stcr, A. M. Fundamentals of Operating Systems, 3d ed. New York, Springer V?.yv
198-1. Несмотря па то, что (X, составляли па протяжении многих лет ;.. j’
моих особых интересов, что я изучала их в колледже и работала с раж
из них, мне никогда не попадалась эта замечательная книга. he t пеп:>;.
порекомендовал мне Марк Люковски (Mark Lueovsky1 в начале м'к'б. раА
когда высказывал свои пожелания <> том, какой должна н< vivuirriB'a
краткой, ясной и объясняющей все где-то на 150 страницах. Хота, т..7,.,
оглядываешься назад, чти пожелания кажутся забавными, указанную -.:..;)Гг.
обязательно должен щючесгь каждый, кто хочет ионян. основы сгрух-.у;>(",
ОС. Они написана с вдохновением.
hers. Glcnfokl 1. Advances in ComputerArchitecture, 2d cd. New Aork: V";ev
and Sons, 1982.
saecker, Philip A. “Software Layering on VMS.” DEC Frolessioiial (Scptem’*т (9Sst;
58—15. Кратко рассмотрено значение многослойное!н и модульное ftUi
ОС применительно к VMS.
3eterson, Janies L., and Abraham Silbcrschatz. Operating System Concepts, 2d l4|.
Reading, Mass: Addison-Wesley Publishing < ompany, 1985. Aia книга бы :? моим
учебником в колледже и очень хорошим подспорьем впоследствии. П сто-
ящее время, вероятно, есть повое издание, но п что оказалось под4'vtsatHM
.для моих целей. Вместе с книгой Таненбаума (Tanciibaiini) по проестровж
ншо ОС и фундаментальной книгой Листера (Lister) опа составила основу
(библиотеки, которая помогла мне систематизировать (ющее представление о
Windows NT.
Pollack, Fred, Kevin Kahn, Г. Don Dennis, Gerald Holzhanuner, Herman DTJodgv.aiKl
Steve Toiopka. “|BiiN:J An Object-Oriented Distributed Operating System.”
Proceedings, Spring IEEE Compcon, Febniary 199tj.
Tancnbaum, Andrew S. Operating Systems: Design and Implementation, f-ngiewood
Cliffs, NJ.: Prentice- Hall, Inc., 1987. Таненбау м неподражаем в сноси пн л юно-
сти писать об ОС понятно и интересно. Из этой книги я получила <>. и< '“,ную
информацию о моделях ОС. и основах синхронизации. Спасибо Рону ЬурФ
(Ron Burk), который порекомендовал .мне ее и одолжил па три годл t ы«>
личный экзем! гтяр.
’Watson, Richaid W. “lire Architecture of Future Operating Systems.” Доклад,
ставленный на конференции Gray Users <Iroup Meeting, Iokiio. сснтяорь 1‘- - •
аботка исключений
Levin, Roy. “Program Structures lor Exceptional Conditions Handling.’ Hay m|f
доклад, с|гакультет информатики (Computer Science) университет.'! Xap,,L
гп—Меллона, июнь 19'7?.
Roberts, Eric S. “Implementing Exceptions in C.” System Research Center :;.ep|,ft‘
Digital Equipment Corp Million, Man’ll 1989.
(дцтернационализация и Unicode
Freytag, Asmtis. “Program Migration to Unicode.” Proceedings of the I nicotic Imple-
mentor's Workshop, Mountain View, California, August 1901. Асмус очень помог
мне документацией и советами на темы интернационализации и Unicode.
Рисунок в гл. 2, иллюстрирующий раскладку кодового набора Unicode, был
заимствован из данной публикации.
Hall, William S. “Adapt Your Program for Worldwide Use with Windows Internationali-
zation Support.” Microsoft Systems Journal (November.(December 1991): 29-58. В
статье поясняются основные положения, которые другие авторы считают
общеизвестными. ('. этой статьи, а также статьи Шелдона (Sheldon) хорошо
начинат ь, если Вы хотите научиться писать программы, поддерживающие
hi । терна । цюнал 11за i ц по.
Sheldon. Kenneth М. “ASCII Goes Global.” Byte (July 1991): 198 16.
The Unicode Consortium, the Unicode Standard: World-Wide Character Encoding,
version 1.0. 2 vols. Reading, Mass.: Addison-Wesley Publishing Company, 1991—92.
Консорциум Unicode занимается поддержкой и внедрением стандарта и
спонсирует текущие работы, связанные с его реализацией. (The Unicode
Consortium, 1965 Charleston Road, Mountain View, California 9|0|?,_)
Ввод-вывод и файловые системы
Duncan. Ray. “Design Goals and Implementation of the New High Performance File
System.” Microsoft Systems Journal (September 1989): ] [А. Данная статья, хотя
и посвящена в основном HPFS, включает краткое техническое объяснеиие
того. почему’ мы уже переросли систему FAT. Описано также понятие ‘ уста-
навливаемой файловой системы” — новой возможности, реализованной в
Windows NT.
Mach
В начале работ ы над киш ой я читала все документы и статьи по Mach, которые
могла найти, так как Mach была новой клиент—серверной ОС, во многом сход-
ной с Windows NT. Сейчас, несомненно, появились новые публикации, так как
я не обновляла синеок ли тературы на эту тему последние год-два. Рик Рашид
(Rick Rashid) начал работу в .Microsoft в конце 1991 Пзда в должности руково-
дителя исследований (Director of Research) вновь сформированной исследова-
тельской группы. Хотя он любезно согласился просмотреть части этой книги,
я сожалею, что нс смогла в полной мере воспользоваться его опы том, так как
он пришел в Microsoft незадолго до издания книги Все* ошибки и неточности
относительно Mach в этой книге - это полностью моя вина.
Accelta, М., R. Baron, W. Bolosky, D. Golub, R. Rashid, A. Tevanian, and M. Young.
“Mach: A New Kernel Foundation for UNIX Development.” Научный доклад,
факультет информатики (Computer Science) университета Карнеги-Мелло-
на, апрель 1986.
□ НОВЫ WINDOWS N(
Baron, Victor, Riehau.i Rashid, I lien Siegel, Avadis Turanian, Jr., and Michaei Т-оц,,.,
“Mach i: A Mui!ipr--cess<>r < iriented Operating Svs>ent an-.! F.nvir- >.i ~
Proceedings, New Computing 1-jnininments: Parallel, Vector, Systolic, । t
Arthur Wotik. SIAM, piso.
Rashid, Richard, “Im.m RIG -<• Accent t<- Mach- The Lv-.-iuiion of a Network i iper;;- -
Sv.'tein.” Научный ,uncia.i, факулвтс! И1к|*>рматнк>1 -C-.-mptiter Scic!;,-.-
вереи'!can Карнеги- Me. t. в ma, аыугт 1<>е~.
Rashid, Richard. “Threads of a New Sy.-u.-m.” /,’Л7\ A’-v/err ( Aug-.i.'-r l‘>Sor j'-
Rashid, Richard, Avadis Tetanian,Jr., .Michael Y<iting, 1 iavid < Jt-iuix lv >1 at! lius,.., ; v=,.
Black, William B< ilosky and J< niathan Chew. “Machine-lndeix-ndent Virui;,! X; ,lv
Management lor Paged I’niproecsMir and Mtiliipro-. essor Architecture.-." i.'-cee-
dings, .Second Internal:'>нп! (лмнегевее tin Architectural Siifipin for e,-.:
tiling l anguages and ! Jperatti g Systems, li'J-C,
I'cvanian, Axadis. Jr. “Aiehileclure b'dependt.a V .-aal Memory Ak:•(>,
Parallel and Distributed Environments; ) hr Mach Approach.” .Чиесерт;":,-;-; lta
степень докн>pa фи.S'lcciijir-i1., yiiitnepi итог Кар чти-Мегьпа,.ic' i” , •'s'?
Tet .inian, Avadis, Jr. “Mach: A New Basis fur r'uuirc 1 - M \ I level* ipment.’' Pr >.. ‘di.ags,
Autumn El cctггяорь P-Wst..
'levanian, Avadis, Jr., uir hard Rasf-id, ! ke’id B. < J- >!i;!-., ! Javid L. Black, i-ri-. <> _t and
Mkhaci W. Young. “Mach Threads and rhe ! :N!X i'.ernel: The Baltic Sr,- с..ич-м.”
Научный иагаад. <|гагу.;-.гет iiii't.-p.'-taaг и >t.'c'r.r-ctei Si'ieuee- y:.:..-.‘jxar'crt
Карнеги- Mc.-i.-iona, август rJs,”.
обработка
My.'ibTiiiipottcce-lOtiasi input*rnra — :/m о.ана и.-, тем, на которые •л-уГ- иптм-ано
M'j.i-i райот, u-x Ko'ibKv с- го врем", когда >• H'j-ia.;a раГнчу над хг.»й -n--or. оы.ч-
не так' у.к мп<-г< > < >С дай симм-стрччп- >и мутьтиироиессирной оор; roT-tc iSMP).
Кому-то chic иредстопг нлингал- iritmy о труиютл пр->ект»цюи нт- e’cciv.u
SMP Зао важна-! тема.
Maples, anti Douglas i.ogan. “The Ai'vanfay.rs -- ar- Adaptive M.-i.i;'.'. ess*’!
Architect tire.” Pneect lings. New G -niputing iat»'in intents: f ’anile!, Met. •, 'i ’
edited by \nhur W -.tuk. SI AM, 1°-Чо.
I Jlcinick, I'l icr Nl. /< i''it"e;Ail>;iri:bitlS->ll О ?,/;/«;/-A>CiVS;Ann Ariior, M-Cii.: • «w-г. и
Press, !lJK2. (Не напечатай;1,. Hiгстав.i;hTia I nkersity Micrc-iiims liiierr.;.,.. Jb '
иоде мнк|>оф|1.'11,ма.)
William, Ъ -m. “Real -Time I Ni‘< I чл e:< >p> Mtiliipnu essmg Musek-.’’ t - X,"-
i March loo | у i .’о- ч j, в статте рассчатрвнакrrca ризничные aciieio । - 1
lipoiiercopnon .--ipa An ей. саом числе <. пмметрттои, ei т;»!!- - sт.ч.:«!:!:К’|С * •
стемы н еравнепнп c<-е г’йо t’Ba.ianiibiMn, t-ццн-fvii >кпр.-lu.n и up >:"ccc-
i. p-. VI.CTI-.': i.
ьиг>лио1 рофия
Сети
Birrcll, Л. i >. and В. J. Nelson. “Implementing Remote Procedure Calls.” ACM Trtms/u -
litms on Computer Systems (February 19.41): v»-5Q. Юкка нческая работа.
Microsoft Corporation. Remote Procedure Cult Programmer's Guide and Rejerence,
1992. Определяющее нес понятия н хорошо написанное руководство но
Microsoft RPC. (ктюнано на спецификации RFC Digital Equipment Corporation,
которая была модифицирована н адаптирована в Microsoft Дасоном Мюрреем
(John Murray)
Petrosky, Mary. “Microsoft’s Master Plan.” ELV Technology (April l‘>9] j; 7] 7u. Имен
но в этой статье новая система Windows NT была названа “многоголовой
гидрой”, о чем упомянуто и гл. 5. Я заимствовали этот эпитет, так как он
делает изложение более занятным. Название этой статьи, по моему, тоже...
irv скажем, забавное.
Ryan, Ralph. IAN Manager, Я Programmer's Guide. Redmond, Wash.: Microsoft
Press. 1990.
Tanenbaum, Andrew S. Computer Networks, 2d cd. Englewood Cliffs, NJ.: Prentice
Hall, Inc., 1989. В который раз Тапенбаум делает интересным п ясным изло-
жение темы, связанной с ОС. В этот раз суха и скучна гема, но не Тапенбаум.
Я заимствовала из этой книги сведения о справочной модели OSI п о разных
мелочах, связанных с сетями.
Tanenbaum, Andrew S., and Robbert \ an Rencsse. “Distributed Operating Systems.”. ACM
Computer Surreys (1985): 110-~0.
Объекты
Coad, Peter, and Edward Yourdon. ()bject-(iriented Analysis. Englewood Cliffs, NJ.:
Prentice—Hall, Inc., 1990. Я не рекомендую эту книгу для изучения объектно-
ориентированного подхода, по в пей дастся выразительное визуальное пред-
ставление объектов. Я использовала способ построения их самых ирехтых
схем для иллюстрагши обтх-ктов исполнительной системы NT.
Jones, Anita К. “The Object Model: A Conceptual Tool for Structuring Software.” In
Lecture Notes in Computer Science, edited by: C. Goods и J. Hartmanis. New—York:
Springer-Verlag, 1978. В статье ясно изложено, что такое обьекты н как они
связаны с ОС. Обсуждается три области применения объектов в < X': именова-
ние, защита и синхронизация Именно в этих областях главным образ,ом и
применяются обьекты исполнительной системой NT. Данная статья была
настоя11 ten находкой.
Meyer, Bertrand. Object-Аiriented Sttjhcare Constnution. Hertfordshire, United Kingdom:
Prentice-Hall International, 1988. Три года назад это была единственная книга,
которую я смогла найти, где действительно объяснялось, что такое объект-
но-^ ориентированное программирование и зачем оно Вам может понадо-
биться. Первые четыре главы книги Мейера содержат наилучшее, из извест-
ных мне, введение в принципы < хтьекп к >-ориентированного подхода.
НОВЫ WINDOWS NT
<2
lacohucci, Ed. (/л J Programmers Guide. Berkeley. Calif.: (Jsbonie Met»raw— 11 ill, i
Kogan, M. S„ and E. L Rawson 111. ‘‘The Design of Operating System. 2.” HIM .y’s
Journal Г, no. 2 (1988): 40 100.
letwin, Gordon. Inside C>y J. Redmond. Wash.: Microsoft Press, 1988. Х.тги e:
Лствнпа естественно отлнчасгея по форме и содержанию, ее t ущести
оправдывало то, что я написала siy каину. Мы гакже заимствовали назва
Спасибо, Гордон
Microsoft Corporation. Microsoft ttferating System 2 Programmer’s Refen
version 1.1, vol. 1, 198*». Written by Brag 1 Pastings, Stan Krntc, I >onn Morw. К
Walden, and Dan Weston.
SIX/UNIX
Bach, Maurice J. The Design of the I A/.V <tj>eraling System. Englewood (.tills,
Prentice Hall, Inc., 1986.
IEEE, Portable <"feratiuy. System Interface for Gumfmter F.tirirmtnienis. Стан
IEEE 1005.1 Ю88, loss.
I .ewine, I Jonald. P< >St.\ Pn grammer’s < luide, U riling Portable ! A/.V Programs. Xe'-
Mass.: O’Reilly X Assix iales. Inc, inoj. Зга книга досталась мне no itac.ie-
от Эллен Апкок-Райт (Ellen Aycock—Wright), работавшей над.
подсистемы POSIX для Windows NT, когда та покинула Microsoft ti u*-i!
более зеленых пастбищ. Mik жаль, чао я нс получила эту книгу годом
нк? - при беглом просмотре она кажется очень интересной.
оцессы, потоки и параллельность
Birrell, Andrew D. An Introduction lo Progranmring with threads. System Re.-.
Center (SRC) Report, Digital Equipment Corporation, о January l°s9. Han ?,
(формацию ч пшока.х управления и 1989 году было нелегко. Sib'. Ф"
Digital опублнкс.ва.т несколько ранних ,[ок.ча,1он но данной геме, нклк >ча .
< )co6ci 11 to i к >лсз1 к > в да ином докх’мег 11 е < >бсу ждс! и tc oi к >bci цени и. 1 ’са. i. г‘
оповещенин н АРС в нсполнп'1ельно11 chcicmc NT частично основала
богах, выполненных к SKC.
Birrell, Andrew! г,J. V. (lettag, I..1.1 lexning, and R. Levin. Synchroni-.aiiun PGimir'
a \hdtij44>cessur: A Forma! Specification. System Research Center tsRCt Re
Digital Equipment (>>rporati«m, 2<> August IOS".
юцессоры
llennessv, John L. PIS! Processor Architediire. IEEE Iransactioiis on Comp
(Dieember i9s|). Важная работа no процессорной архитектуре, r. i;<m
ра« < матрнваются разли'п пае одпопронег сорные архитектуры и п.х связь
Работа была мне полезна как источник базовых знаний о процессорах RISC
н CISC. В пей также описаны необходимые функции ОС и поддержка нтп.х
(|п 11ши ।й ир< >цесс(срамt1.
Intel Corporation. .svi ;,sy» Programmers Reference Manual, 1;>«i
Intel Corporation. Ц8<> Alicruprocessur Progranmier’s Reference Манна!, 1
Karie, Gerry, and |oc Heinrich. MIPS Rlsri Architecture. Englewood Cliffs, N.L iTeutiec
I kill, Inc., 1*h>2.
MIPS R4<>l,<! Microprocessor User’s Манна!. MIPS Computer Systems, Miimvvalc,
Calif.. l«)dl.
Защита от несанкционированного доступа
Department of Defense Trusted ComputerSystem Evaluation Criteria, Dot) S2OU.2S-
STD, December 198S. Средн специалистов по защите известна как “Оранже-
вая книга”. Beto серию сопутствующих документов коротко называют “Р.щуж
Hoti кол.чекнпсГГ (“The Rainbow Collection”).
Reisinger, David A. “Access (Controls Methods of VAX.VMs.” iHllirnialvm Age (.Inly
Shannon, Tcrrv C. “An Introduction to VAX VMS Security Mechanisms’ and Techni-
ques.” fj»ni[>nter Security f-nr.ia! -I, no. 2 (B>.s~); ,v>—17. Хотя статья посвящена
защите i=. VAX VMS, многие из описанных в nett приемов используются и г;
Windo . s NT.
Виртуальная память
Denning, Peter I. “Virtual Memory.” Computer Surveys (Scpivtiihcr issL^iso
Dry класс hmcckvk> pano.y no вир ксалы юн памяти рекомепдова.’: мне Jiv ilc
р.тцоли (I.ou Perazzoli). (Но его слонам, лта работа подтолкнула со к тому,
ч тобы сиецналнзнронат ю к области виртуальной памяти, и. таким обра-
зом, к определенной степени она ответегш нна за текущее положение Лу и
Microsoft как rvpy но виртуальной памят и.)
Denning, Peter 1 “ I'he Working Set Model for Program Bei’.avior” <S:))ii4:;>netiiiims
<>J At'.M (.May I’to.Sj: 325 53. Dto также- каасснчст кая статья на гему виртуаль-
ной памяти, послуж!шитая теоретическиой основой для pca.iu.iat:mi рабгтчнх
наборов в Windows С Г.
r'itzgcrald, Robert, and Richard Rashid. “ I he Integration of Virtual Meninty
Management and lntcrpro<'css Communication in Accent” “'!M ’lr-:uisucii-4i.<
r>n ( 'iHi/Hiter Systems (May ll>Si>j: 1 I” “*?. Помимо прочего, в зтой статье
обеу.кданися методы Accent, koiорые также нспользсвггся •> нс'емой вирту-
альной памяти Windows N I', а именно, наложенное вычисление и копиро-
вание при записи.
Series 1 >ala!><ю!". Xational Semiconductor Corporation, Santa Cbra, Cali:,
Dra книга, порекомендованная мне Роном Всркссм (Ron Burkj, когда я
J с нивы WIND О w s NT
начала шк ап, про виртуальную память, оказалась для меня большим св р,ь
ризом. В ней, скрытое но введении в архитектуру серии 3201)0, содержится
сжатое, читабельное и довольно полное описание принципов впртуалыт»
памяти. Эта инЦюрмацпя помогла .мне составить вводный раздел к глине
посвященной виртуальной памяти. К сожалению, в книге нс назван ее шочр
(прискорбный обычай в документации компьютерных компаний).
Petzokl, Charles. Programming Windows. Redmond, Wash.: Microsoft Press, lOOn1 ц..
смотря на то, что я скорее пролистывала книгу Петцольда, а не читала се <>-г
корки до корки, задним числом я жалею об этом. В псп среди фрагмептчи',
кода и обсуждений примеров разбросаны кусочки сведении об архитектуре
различных компонентов Windows. Если бы я поняла это раныпе, я сэко-
номила бы время, потраченное на написание главы по Windows. Всем
Windows—программистам известно, что данная книга незаменима при изу-
чении программирования для Windows. Я надеюсь, что Петцольд папшист
такую же по программированию для Win32.
Microsoft Corporation. 1Гг>/32 Application Programming Interface Reference Manual.
2. vols. Redmond, Wash.: Microsoft Press, 1992.
Windows NT
File System
PRESS
Helen Custer
AUTHOR OF INSIDE WINDOWS NT
файловой
системы
NTFS
Хелен Кастер
АВТОР КНИГИ "ОСНОВЫ WINDOWS NT"
Посвящается aul iein>K.oit К-тш
it дедушке ,Imc<>.
Содержание
Предис/з-.. ... ... Зт
Введение.. ......
Г А А В А 4
ЗАЧЕМ ПОНАДОБИЛАСЬ ЕЩЕ ОДНА
ФАЙЛОВАЯ СИСТЕМА?. 335
1.1 Требою; «ия к фоилоьой слот_о юс зкого , ооь. 535
1.1.1 Восстанаьливае...Ю'ь...................... 336
1.1.2 Защита от несом!: зниссвэннс? е- доступа. 337
1.1.3 Избь-точ! ость даннь** и этксзоус." эйчичхль ю/
1.1.4 Диски и файлы большого объема................. Зю
1.2 Новые возможности MTFS.............. ... ... 33®
1.2.1 Множественные потоки ,ланных .... .... 35?
1.2.2 Имена в UNICODE........................ ... GIG
1.2.3 Универсальное средство инде: г.аци: *........ 340
1.2.4 Переназначение плохих кластер os. 34г'
1.2.5 Поддержка POSJX............................ 341
1.2.6 Сменные диски. ..... ..... 341
Г А А В А 2
МОДЕЛИ NTFS........... .. .................. зз:
2.1 Многоуровневая ?ис дель драгвеоа..... ..
2.2 Модели реляционной базы данных
и обработки транзакций...... .. :45
2.3 Объектная модель ..
Г А А В А 3
СТРУКТУРА ФАЙЛОВОЙ СИСТЕМЫ..................................
3.1 Понятия и термины №
3.2 Структура на диске...
3.3 Индексация имен файла......... ...............
3.4 Файлы метаданных С'ТР8и'.асР¥-'’'>чны1-*файл ____
Г А А В А 4
ВОССТАНАВЛИВАЕМОСТЬ.................. 36"
WINDOWS NT
4.1 Эволюция файловых систем .......... 3'4
4.1.1 Файловые системы с точной записью .......... 254
4.1.2 Файловые системы с отложенной записью...
4.1.3 Восстанавливаемые файловые системы ........
4.2 Протоколирование транзакций.................... ?„*;7
4.2.1 Сервис журнала транзакций................. 357
4.2.2 Журнал транзакций .......................... Злу
4.2.2.1 Записи модификации................. .'59
4.2.2.2 Записи контрольной точки.............
4.3 Восстановление................................... 373
4.3.1 Проход анализа.............................. 373
4.3.2 Проход повтора.............................. 374
4.3.3 Проход отмены............................. 375
Г А А В А 5
УПРАВЛЕНИЕ ТОМАМИ
И ОТКАЗОУСТОЙЧИВОСТЬ................................. 377
5.1 Возможности управления томами.................... 377
5.1.1 Наборы томов................................ 377
5.1.2 Чередование дисков.......................... 378
5.2 Отказоустойчивые тома............................ 379
5.2.1 Зеркальные наборы........................... 380
5.2.2 Дуплексные наборы........................... 380
5.2.3 Чередование дисков с записью четности ...... 380
5.2.4 Замена секторов........................... 382
5.3 Восстановление плохих кластеров в NTFS........... 382
Г А А В А 6
СЖАТИЕ ДАННЫХ........................................ 387
6.1 Сжатие разреженного файла .. 338
6.2 Сжатие обычных данных............................ 390
ГААВА 7
ГЕНЕРАЦИЯ ИМЕН ФАЙЛОВ MS-DOS......................... 393
Заключение......................................... 39/
Библиография......................................... 399
ПРЕДИСЛОВИЕ
чРайловая система NT (NTFS) - эго один из нескольких интересных компонен-
тов Windows NT, которые я не успела рассмотреть в своей предыдущей кише,
"Основы Windows NT". Падежная дисковая памят ь критически важна для опера-
ционной системы высокого уровня, поэтому я и написала э ту книгу, посвящен-
ную NTFS. При написании книги подразумевалось, что читатель имеет представ-
ление об архитектуре Windows XT, а также об основных принципах кэширова-
ния дисков и виртуальной памяти.
Мне было очень приятно работай, над этой книгой совместно с группой
разработчиков файловой системы. Особенно я благодарна Тому Миллеру (Тли
Miller), который щедро делился своим опытом и соображениями и нс жалел для
меня времени, а также Гэри Кимуре (Clary Kimura) за выражение альтернативных
точек зрения на устуюйство файловых систем и за помощь с техническими об-
зорами. Спасибо также Бобу Рипну (Bob Rinne), Брайану Эндрю (Brian Andrew),
Питеру Гэлвину (Piter Calvin), Майку Глассу (Mike Glass), Дэвиду Гобелу (David
Goebel), Норбергу Кастере у (Norbert Kosters), Мэттью Брэдбсрну (Matthew
Bradburn) и Биллу Мак-Джону (Bill Mcjohn). Я пользуюсь также случаем снова
поблагодарить Дэйва Катлера (Dave- Cutler), Ду Пераццоли (Lou Perazzoli) и Рона
Берка (Ron Burk) за поддержку моей работы, а также талантливых сотрудников
Microsoft Press за исключительную помощьирп редактировании и издании книги.
Наконец, множество благодарностей моим партнерам в гцхлило.м году,
особенно вам, Майкл, Джилл. Марша и Триш. Вы научили меня смыслу простых
физических усилий (не беда, что повредила плечо и сломала палец на ноге).
.Хелен К. Касте]>
Лн]к-лъ 1994
>А
ВВЕДЕНИЕ
Q/айловая система NT (NTFS) была создана специально для (ТС W indows NT.
NTFS .-n-о новая файловая система (ФС) с разнообразными возможностями,
благодаря которым опа соответствует среде ОС высокого уровня Windows NT.
Том Миллер ( loin .Miller), архитектор NTFS1, обладает большим опытом разра-
ботки сис тем обработки транзакций и восстанавливаемых баз данных, и его зна-
ния в этих областях наглядно проявились в дизайне и возможностях NTFS.
NTFS 1111с.-1ласы1араллелыю с Windows NT. Примерно через два года после
начала работы над проектом Windows NT инженеры начали эксплуатировать
новую ОС и использовать ее в качестве среды разработки. Спустя год NTFS уже
была достаточно стабильно!, и разработчикам стали рекомендовать конверти-
ровать своих жесткие диски с Ф(i FAT на NTFS, '[ом Миллер описывает этот пери-
од несколько растерянно:
Рагчла над файловой сиетехь Щ это, пожалуй, самое ужасное [при разработке
операционной системы). Если обнаружилась ошибка в ядре системы, пли ч то
ннбу.ть странное происходите дисплеем, то можно lipocio переза rpvnn'i. ма
шине и продолжиIь pjfxnv Но если что-то случилось е жестким диском, то
часто дальнейшая работа вообще невозможна. Всех страшно раздражают отнб
кн к файловой системе. Никому не хочется, чтобы его постоянная измять era.la
непостоянной.
Если создаваемая (X' nci юльзустся также как платформа для разработки, т( >
каждый день есть риск наткнуться па программную ошибку. Разработчикам это
приносит много неудобств и разочаровании, но .зато такое использование сис-
темы гарантирует быстрое обнаружение и исправление ошибок, а гакже позво-
ляет обнаружить больше ошибок, чем при автономном тестировании. Однако
пользователи не должны иметь дело с нестабильной системой, а особенно с не
стабильной ФС. Их постоянная дисковая память должна оставаться постоян-
ной. I кл сря жесткого диска или ело части это один из наиболее болезненных
для пользователя сбоев системы.
Именно заботой о надежности дисковой памяти пользователя и руковод-
ствовались разработчики NTFS. Том п группа разработки NTFS заложили основы
построения ФС, которая была бы не только более надежна и безопасна, чем су-
ществующие, но также имела бы важное дополнительное свойство: была восста-
наатваемой (recoverable). NTFS обладает возможностью восстановления самой
себя в случае сбоя (Xi или оборудования, гак что дисковый том (раздел) остается
доступным и целостным, а структура каталогов не нарушается.
NTFS подходит для пользователей всех категорий, но должна бы ть особенно
привлекательной для тех, кто в пропетом работал главным образом с ОС мини-
компьютеров ИЛ11 больших ЭВМ т. с. с системами, разработчики которых уделя-
ли особое внимание надежности и безопасности храпения данных. Своими воз-
можностями восстановления N 1FS создаст новый стантарт надежности для ФС
1 В числе других основных участников разработки Шри Кимура (Gary Kimura), 1>рапан Эндрю (Brian
Andrew) и Давид !>«'и‘Л •David G<.c!>ch.
Цель -поп книги описать структуру и фупкцнонпрсшапне М1Ч Чём |.г
менее, некоторое отклонение и стороне процесса ее создания кажется уме.
ным: и П' и< >му, что написание ФС эго д< сагам и трудная работа, н поп .му, ч-г,
NTFS вводит новый <|юрмат хранилища файле»’,. Га. I отвечает па вопрос-,,
почему разработчики решили все же создавать NTFS, несмотря на все связан; -
с этим сложное i n.
В гл. 2 описаны теоретические модели, положенные в основе NTFS, 4 (
гл. 5 — детали внутренней структуры ФС. В гл. -I вводится поня тие восстана
ваемостн ФС п объясняется, каким образом NTFS восстанавливает том Л'..де
сбоя. Другое понос свойство - устойчивость к отказам жестких дисков - м. с,
использоваты я с любой из ФС Windows NT. Но сочетание се с NTFS даст оо •>*; -г
преимуществ, тк как использует восстанавливаемость NTFS для получения
особо надежного дискового хранилища. Отказоустойчивости пос вящена "
Гл. (> описывает сжатие данных в NTFS - эта встроенная возможность и-.'яви-
лась в Windows NT версии 5.5. В гл. 7 обсуждается генерация короткого имени
фаГгла — возможность NTFS, позволяющая клиентам MS-DOS обращаться к рай-
лам с длинными именами.
ЗАЧЕМ ПОНАДОБИЛАСЬ ЕЩЕ
ОДНА ФАЙЛОВАЯ СИСТЕМА?
В 1988 году Microsoft уже поддерживала две файловые спслемы (ФС): дня Ms
DOS и Microsoft Windows это была ФС. 1-АТ, а для ()S,'2 UPFs (high performance
filesystem — высокопроизводи’тельпая ФС). Вполне естественно, что Том Миллер
(Tom Miller) и дрхтпе разработчики, отвечавшие за ФС. для Windows NT, много
размышляли над тем, нужна ли вообще для псе новая ФС. К сожалению, и 1-ЛТ, и
HPFS страдали от ограничении, которые делали их либо менее надежными, чем
следовало быть ФС для Windows NT, либо i кснособнымп поддерживать болыш ie
системы, для работы с которыми она предназначалась. Пек ле тщательного ана-
лиза разработчики решили создать новую ФС — но, тем не менее, на N ITS очень
сильно сказалось влияние FAT и I1PFS, а также некоторых особенностей, необхо-
димых для поддержки стандарта POSIX1.
В первом разделе этой главы описаны требования, предъявляемые к ФС.
Windows NT клиент- серверными и бизнес -приложениями высокой степени
сложности. Во втором разделе рассмотрены дополнительные возможности, ре-
ализованные в NTFS для этих приложений.
1.1 Требования к файловой системе
высокого уровня
MS-DC )S нспользхст ФС FAT, которая была изначально создана для работы с гиб-
кими дисками относительно небольшого размера, г. основном, I Мбайз или ме-
нее. Когда жесткие диски стали стандартным запоминающим устройством для
персональных компьютеров и постепенно увеличились в объеме, стали мешан»
ограничения ЕАТ. Для устранения некоторых из них в операционной системе
OS/2 была введена HPFS. Последняя, например, значительно уменьшила время
доступа к файлам в больших каталогах и могла использовани я е жесткими дис-
ками объемом до -I Гбайт2 (гигабайт ~ миллиард байт).
1 Набор международны* стаи.саркш дчя интерфейсов о» пин HNLX, IS< > li;c <>о |5 i iIEFli Sun
dard lud.'s 1 Poii).
- Позднее размер дисков, которые могла ноддсряшвать HITS, «мл увеличен до .* гераоайт пера
байт = триллион Г>л‘п;
Файловая система EAT отличию работала с мале нькими .инекамн, а 1 им-г
д< >йаин.ча не к< m ,рые новые возможности, более эффективный д< ч туп к j ;-лд4
и пол цержку Hi .-lire чей б< •н.н1< >гп раз ера. < >днак< • нп одна нз этих *1”'. не .з....
аГх о.нотио иодхо.т.нпей для Windows XT — операнп-. iimoii 1Т.пт,уы (!
назначенной для таких сложных, оты-гсп .-иных при.к «.riniii, как:
клнент-сер! ерпые нр.'-Ю-.ения (фан.i-eep... ры, сернср-.' вычисл hi
и серь .‘pi>i ба:-. данных"):
• сложные технические и научные приложения;
сетевые приложения для twi.ibiiinx .,< >рш >ратпы1ых снсим.
. L'im таких приложений ш.ц'окая надежиость‘l»(S н загцпта =н иесанкдг- ।
|Х»гД11ноп> доступа ;-по iict-ox'i.'ui.moc ус.н•вне. 1ак, и< .прежде;! не га ж; и
пых п cuciv.Mc управления ко.',дуц1еым движением или к баныч«.К-; >
базы .чанных может прннест значите ..ibiiuii ущерб и вызвать страши.,:..
Трсбованн.ч к к; ipiiopai пвным Ф< шлисчаюг: споеобн- >еть ш ,сстал; л
данных; защиту <>; не.;анкнионнрованп'>:*о доступа к данным; оп.азоуст-л i
кос!!,»! поддержку носителей данных, < »ижм которых превышает лаже
жнваемый llf’ES.
1.1.1 Восстанавливаемость
Что касается лнековс.’о ввода-вы воду, пользователи персональных к--ь ле
ров склонны г. первую < .чередь ::аб< л иться . • скорости — они прост, х- лмт, чн;-
бы их рабша шла быстрее. Однако, ио мере того как благодаря \\ Iгл';-••.;• .'.Г
персональным компьютер начинает использоваться в самых различных ...;дах
деятельности и в постоянно растущем числе корпораций, становится С <ил
важным обеспечить «гадежтпхтьхранящихся в ок геме данных, имеет т.-.г-
бы увеличить екор<к-п> достуна н данным на диске. Другими словами, ес-ш.. ... а‘
сбои системы данные на ,ш< ке будут повреж.в.шы вли станут нс.чосгул"........, .<>
скорость г.ы11о,11кл1!1я нре.дшесгную!!;их операций ыюда-вывода ока-Л” с с >
вершетнк । нссушептн.'|1н<ай.
Ч тобы л/ГЕ> удовлетворяла требованиям к надеж:в < ru как \pimiuti:i.,: „- '
пых и с '.есисч:шала занипу .ж жгупа к данным, опт была разработана как ж
пашшг.аемая ФС, псиользу >щая мо,;е и. обрубе,->кп транзакций. В слух-.с от
ключе, пня ’ли rauiij: иле. друки о систем! и чю сбоя \'1 Г> i;> 4'<”ra»iai‘.Hii:ae i .U;<’
'iov,a и нозвратшт их в iie.iiorruoe состояние. < Ми-рация г.оеетап-.>.„ie<’....я . ।
г;Ы1!о,1няете;1 автомат г;е< кн при нервом после сбоя < юращепии Доску
мае! всег= ...лишь нееколыа > сскуи,1, i ieзависимо от размера диска. К|и пц-к < 1,1
сиоях жизненно ,ч;;ла)»;'.; cernipoB X I ES применяет tr-.Giae т-нюс x'paucuiii. >"
что если диск иоврежк-н водном uvci’c, критические данные <)•«' на гомс< ” 'во'1'
ея но—прежнем', листу.1!гь.'.''и. г>та с.збыточи; ть данных X i ES upiiir., л гл.”' |К
< /г;! и ч зет ее о г стр* ктур данных па диске <i42 l-'.VE MS 1К )S и I IP!’S< iS i.,c
•;1Ш:Ь, >.u ia i,! uiiiM секте [к T с к; i.iTir-icci.iiMH данными ФС. i-.c.in ;:рп чтени: /’юл’
нз таких секто-я -г. кр» я;сх< >.;вт • Ч1ыбка, т- > теряется :пц|.ч>рман;1я |йхт< , т« иж-.
’ Л-.лц мцип ~,£Г и 41*' > в . •. ,!пч л .о книц’ О1Ч11Ш1., ii,iii,ir:ii, цк к.,,, в шг п*1
"biiii.'inbi и -.-kik ан пет i'll, «ими him lov "1<и1‘11шы11 драив...; । Wh«*ou> XT. -1аль ..-I'nmin u ' j <»•’
I ' i'b.i, ..л; Г T ' и-.",,-1. i-ч ui.'i х i||KHgi..-hih-ix>* .'каике >пчшк -и.
4Д2 Защита от несанкционированного доступа
Защита дачных от нееа'йщн;>iiupi>raiin<>n> дослуна имеет nepni-erencii так? зна-
чение я.;я тех •;<е'мсрчегкк?: и привичельстиепных организаций, которые
рабатыкаюг закрытую пли не Допускающую иесанкннопн.р! данных изменений
информацию например. .ня банков, больниц или хчреждечнй, сы1:::;1::<ых .-
об<>р< 'И' н. Таким ih ищи.' ii.aiv.i»!,-! нужны га ран mu, что их данные бур •;•; aa;>
ны от i!ec:!>ii<t'j.i<-.i:ii;-><!naHiiofv> осгуца.
()pi”i!i';.''saui!H i.'oiiTpi. in доступа в N'i !’b оешч'редстел нн! i следует из , ч"-ь.? д-~
ной модели х\ indows NT. < >ткрытый файч иредетавлаеге:: •< виде Файд,.у- .-?;
объекта, .чсскрннтор чаь.нты котор.н-о хранится на ,:;нг,е гик чае:ь '.ай.-.а1
Прежде чем процесс см» «кет < и крыть описатель люб, нм ,нгьекта, г. том «теле
файлового, сне гема кон н яria ,i« д аyiia WinU’ ws \ <’ ,.р-.шериет, естт». ш у И| .пег <•;;
соо гвс re t вук инне нрава. Дгскрин'Ц д' защиты,.-. е- щесаппн с [ребмпаинем, мт. -.бы
пользователь зарегта трпрыиддся при i-.xo.-ie г, систему и указал гной пароль, га-
рантирует, ч1ч никакой процесс не сможет н< ид чпть/к ктуп к файлу если т» сгькс
ссхлпстегкующне нрава не были налпачеиы ему ;!дм|п111стр.тгоро,ч < неде ль, или
владельце?.! файла.
1.1.3 Избыточность данных и отказоустойчивость
Кроме восстана—нижемогти данных ФС, нега и-«рым п-.ьн.-к косят net oxo
димо, чтобы их собственные,чанные не подперта-и ?ь опасности при отклю
ченпн питания млн фатальном сбое систе-.ы <.ре.:сгка ц«кч тан< зяенп \> }>
1‘арлнтпрунп' возмо-.ы ц-гь iipo.'iosoKciiiiM раб< П'ы» *1>С па юмо, однако i o.-ihoi
восстановление ии.!ьзо11ательскт1\ файлов не .'араитирусня. Для бан Конских
и других >.ipii.'i< i-к'гнпй, и которых потеря файлк, >. ..-.знпых до ккиа б).;т>, ;к-
ключепа, .доп<е.лите.чьный уровень защиты оГччт iii-.яется благо.я.арг ;:збы-
точ н< к т! • да инь: х
Miiorovpot;<iei4ia модеяь драйвера \Х >\v> NT позволяет N'IT'S впаюклтец-
ствонатьсдрайвером <гпз!.«»у<тойчи1юг<<днекп. который, в свою очередь, обра
щаетея к драйверу жесткого диска для записи ;апных на диск г>го позволяе!
системе с Wini.iows N T opranii::or.:n отказоус:-’йчнвос дигкогое хранчлиик
данных, установки .в ин :ип1гге.;1Ы11.1г>1чрайкер5..Т|'.1:1Йвер1>Т1газ< >\с гопчпвоги дмек;
зеркально о-пюражзег (дублирует) информацию с одн-з-го диска на другой, тж
что всегда можно восподьжяегпля избыточной копией 1>гот трангс'р засю
позволяет “размалывать” данные по грс-с, и «'ю.чег дискам, та |ь::у;! зыи-ыг-Щ!;
одного днск:1 л.ля хранения информации о чегноег!!, Кечи данные ня одном н;
дшков белуг :i< .теряны, ,'!.pani;cp в еостхвпши га кеты в и :и !.ь сод*, ржняке диск;
при иомыщц операции “кеглючанлцее il.'lll”"
’ Sujk-C 1 :X>V Ki ШИ* ‘-Mal-J Ч •/.'КГ-ШПО. «Д-. ии.нгы и фниловыл OO'brKiJN СМ ‘
Wniiiairs V7'*“ iji x < и и м • п (х?ль ч<х вун.Г и i. S а к*
’’ I •< чъ* О м >ИЧ1 Го К.1 liver • я 1ОЛЫСО В Witv :О»Х Ч NT ^Капсж с .‘‘{.TVt-1
" » ЛЮС обнос 1Ь О1КЛ Ю. СТОПЧИ ВОН) ,.'Х1ИВх‘:М СОТДЛВ.НЬ ЛГ;«1С1ЛЬП-.1О КОПИЮ /Ш.'КЛ . OOf К "И IB* :•! с HVIIII
фикапип ч t” -I I н- .ноств unit-, и “ hhii.iv <х5л:кт*4ми Ка;п » ,о * i р 5 к
PaH-.TSOn И Лр в IHVHtOi:».f t ЛИ В М . г-’ КН
.1.4 Диски и файлы большого объема
В инженерных н научных приложениях часто требуется хранить и обраба-;,,
вать очень большие объемы информации. В настоящее время вполне обы-щ,,
жесткие диски размером более 2 Гбайт и дисковые массивы обтсмом S
10 Гбайт. Поддержка очень больших .дисков н больших файлов в NTFS реал:
вана эффективнее, чем в FXT и в HPFS.
Файловая спсгема ГАТ использует 1аблпцу 16-разрядных элсмситт .к д1а
хранения информации о распределении пространства на томе. Единиц..
распределения памяти являются кластеры (clusters; одинакового размер-:., :!а
которые разделяется том, а так как каждому кластеру должен быть присвоен
уникальный 16-разрядный номер, то FAT поддерживает максимально 2"’, П11
65.556 кластеров на одном томе (хотя некоторую часть этого пр<х,тр:1Ш'т!у
FAT резервирует для собе'гвст шых нужд). Размер кластера можно увеличивать
или уменьшать в зависимости от размера тома. < )днако, когда размер тома по-
вышает некоторую величину, кластеры становятся слишком большими, что ве-
дет к увеличению объема неиспользуемого дискового пртх'транстна гак на-
зываемой внутренней фрагментации (internal fragmentation). Например, дчя
диска объемом об Мбайт достаточен размер кластера 1 Кбайт, однако диск
объемом 640 Мбайт требует еже кластера размером в 10 Кбайт. Так как размер
кластера должен быт ь степенью двойки, то для диска б4<> Мбайт фактически ис-
пользуется кластер в 16 Кбайт, т.е. пр<хтранство выделяется порциями no in Кбайт.
Если размер файла равен, например, 512 бант или 1” Кбайт, го для храпения
данных используется только част ь выделенного пространства. В любом случае
на томе FAT м< гжет храниться не более 65.518 файлов (максимальное количес тво
доступных кластеров), независимо от размера диска.
HPFS применяет для нумерации единиц распределения пространства 52
разряда, что дает 2V, или более -I миллиардов номеров. Однако HPFS п< поль-
зует числа со знаком, что сокращает число доступных единиц распределения
пространства на томе до 2 миллиардов. FIPFS распределяет пространство на
диске не кластерами, по физическими секторами по 512 байт. Такая нсгпбк- аль
может быть проблемой, особенно на рынках в Азии, где размер аппаратного
сектора дисковых уст]юйств обычно равен 1624 Кбайт. На таких дисках 1IPFS
использовать нельзя, так как диск не может выделять пространство порциями,
размер которых меньше его аппаратного сектора. Кроме того, размер файла и
HPFS огра ничей 1 Гбайт.
NTFS распределяет пространство кластерами и использует для их нумера-
ции 6| разряда. что даст возможткхть иметь 21'1 (свыше 16.()(K).(Ki().60i).,.j()(i.i)!K'/'':',il-
или 16 миллиардов миллиардов) кластеров, каждый размером до I Кбайт; 1’аз"-Р
отдельного файла практически неограничен - до 2*'’ байт. Как и в FAT, [xi.-.a'P
кластера в NTFS может меняться, по нс < хбязателы ю возрастает пропорциона а >!Ю
размеру диска. NTFS использует размер кластера, равный 512 байт, на ма. ичг Ть’Х
лисках и максимальный размер кластера 1 Кбайт на больших*. Хотя для предстаё-
леппя каждого отрезка (run), или выделенного фрагмента диска NTFS использует
<>-| -разрядный (8 байтовый) ад|Х-с, .-mi .'i/lpcva “кодируются” так, что занимаю-' • л
5 до 5 байт для каждого отрезка (пример кодирования адреса см. далее* на рпС-
5- 12 в гл. 5). В HPFS,(ля нредетявления каждого елрезка iктюльзуегся 12 бай:.
* В Window- XT | и мам и:ча.чм1Ы11 по.1'|ера<11в:1смы>Т размер к-шеиера составляет 0-1 K'uaiTi
-r/.vtou 1. xJVj'icnvi I IVFTC-]ДООРТТХОиЬкдапм k^vivjrczivivu :
>1 2 Новые возможности NTFS
Помимо того, *гг<> NTFS является восстанавливаемой, защищенной, надежной и
эффСКТНКНоЙ '14.,ДЛЯ KI1ICI1I ССрВСрНЫХ НДр\1НХ ВЫЧИСЛИТеЛЬНЫХ СИСТГМ 151Я-
сокого класса, разработчики добавили в пес новые возможности, позволяющие
поддерживать самый широкий круг существующих и будущих приложений для
персоналы 1ых к< >.мны< »тер< ш.
4,2.1 Множественные потоки данных
В NTFS каждая единица информации, связанная с файлом, включая его имя, вла-
дельца, отметки времени, содержимое и т. д.. представляется как атрибут файла
(атрибут обьекта). Каждый атрибут состоит из одного типика (stream), т. с. про-
стой последовательности бай тов. гУга обобщенная схема поз1юляет легко добав-
лять к файлу новые атрибуты (и соответственно новые потоки). Поскольку дан-
ные файла - э то “просто еще одни атрибут” и можно добавля ть новые а грибе-
ты. файлы N: IT'S (и каталоги) могут содержать несколько потоков данных.
У файла NTFS ест ь одни пот ок данных по умолчанию, не имеющий имени.
Приложение может созлават ъ дополнительные именованные потоки и обращать-
ся к ним по именам. Во избежание изменений функций ввода -вывода интер-
фейса прикладных программ (application programming interface, \PI) Win32, ко
торым имя файла передается как строковый аргумент, разработчики NTFS при-
бегли к синтаксическому трюку, чтобы предоставит ь приложениям доступ к не-
скольким потокам данных в файле. Так как двоеточие (:) это зарезервирован-
ный символ, оно может служи ть разделителем между именем файла н именем
потока данных, как показано ниже:
П-yl: 1 е. Jcir : stleani.I
Для каждого потока отдельно поддерживаются: выделенный размер (объем за-
резерв) ipoBaniton > для t tct < > д1 ickoboi о пре »crpai icrna), факи imccki i й размер (ста >ль-
ко байт' из зарезервированного пространства использовано вызывающей про-
|раммой) и длина действительных данных (какая часть потока была инициа-
лизирована). Кроме топ», каждый поток имеет отдельный файловый замок, ис-
пользуемый для блокировки фрагментов потока и обеспечения параллельного
доступа. Чтобы сократить объем < наработки, поддерживается совместное исполь-
зование на уровне файлов, а не потоков.
Один из примеров применения нескольких потоков данных в NTFS :/то
храпение данных, созданных в системах Apple Macintosh. ?)ти системы использу-
ют два потока на файл? одни для храпения данных, а другой для хранения рссур-
сов, таких как тип файла и значок, используемый для представления файла. Так
как NTFS допускает множественные потоки данных, то одни пользователь
Macintosh можег скопировать целую папку Macintosh (аналог каталога) на сер-
вер Windows NT, а другой скопировать се с сервера без потерн информации о
ресурсах. Другие приложения также могут пользоваться несколькими по токами
данных. Например, утилита резервного копирования может использовать до-
полнительный поток данных для храпения особых отметок времени. Утилита
архивирования может реализовать иерархическое хранилище, в котором фай-
лы с датой более ранней, чем некоторая .заданная, пли нс используемые в гече
пне некоторого периода времени, перемещал! кт. бы на ленту. Такая утилита г
ла бы скопировать файл па ленчу, установить размер потока /тайных,
умолчанию равным О и добавить новый поим, данных, содержащий имя и
<~п «положение ленты, на которой хранится файл
1.2.2 Имена в UNICODE
Как и Windows NT в целом, NTFS полностью поддерживает liNICOl Mi, пет у,
сто с им волы для хранения имен файлов, каталогов и томов. UNICODE - от-
разрядная кодировка chmimuiob, обеспечивающая уникальное представлен'-^
любого символа любого языка в мире, что <м5лсгчаст перемещение данных
ду странами. UNICODE позволяет усовершенствовать ио.щержку епмволо;
пых языков ио сравнению с той, что существует в FAT и HPFS. 11ослсдннс не: л.<1г.
зуют двухбайтов) ю схему кодировки, в которой одни символы занимают -i Г1;1
а другие 1О; при л ом требуется загрузка различных кодовых страниц, oii| «. пая-
ющих набор доступных символов. UNICODE имеет уникальное представ 1((с
для каждого символа; следовательно, оно нс «ависитогтого, какая кодовая
ннца загружена. Имя каждою каталога и имя файла в путевом имени может
иметь длину до -2SS символов, содержать енмв< ыы l’Ni( л IDE, несколько точек в
пробелы внутри имени.
1.2.3 Универсальное средство индексации
Архитектура NTFN позволяет индексировать атрибуты файлов тома, и бллг.- ,.аря
этому ФС быстро находит файлы, удовлетворяющие некоторому крнтерн!' ••. на-
пример, вс е файлы из .чайного каталога. ЕАТ индексирует' имена файлов, .но не
сортирует их, что замедляет поиск в больших каталогах. 1IPFS индексирует и
сортирует имена файдов, как и NTFS, но последняя позволяет нгщекенрова'Ы!
другие атрибуты файлов. Например, если важным ключом индекса служит имя
автора,то NIT’S можно легко модис|>нцнроватт., чтобы быстро находить вес •; ап-
лы с указанным автором .
1.2.4 Переназначение плохих кластеров
Обычно, если программа пыт ается прочитать данные из плохого сектора ж жка,
то операция чт ения терпит неудачу и данные в соответствующем кластере ста-
новятся недоступными. Однако, если диск отформатирован как отказоустойчи-
вый том NTFS, то драйвер отказоустойчивого диска Windows NT динамически
считывает “хорошую” копню данных, которые хранились в поврежденном сек-
торе, после чего посылает' NTFS предупреждение о том, что этот сектор пл» '1111
NTFS выделяет новый кластер, заменяя тот, в котором находится плохой сектор-
и копирует данные в новый кластер. Она помечает плохой кластер и больше ей’
не использует. ?)та возможность восстановления данных и динамического пере-
назначения плохих кластеров особенно удобна для файл-серверов, отказоус-
тойчивых систем и любых приложений, в которых потеря данных недопустим*1-
‘ В текущей ис|м ни N"l I'S индексируется tivikkh атрып т, являя ищпТся именем файла.
Если слказоуетопчнвый драйвер не был загружен, когда обнаружилось новрсж
дспнс сектора, т< > NTFS г.се рать > заменяет кластер и более его не использует. но
не в сехгоянпн кос <таног.пть данные плохого сектора.
4.2.5 Поддержка POSIX
В состав \Х incknvs XT входит подс истема POsIX, которая выполняет приложения
и процессоры команд l’< )S1X. '.тса возможнос ть гребест. чтобы ФС могла рябо
тать с файлами POSIX. В частности, счандарч Р( )SIX ipeover но.щержкн имен
файлов п катало!он, различающихся чолько регистром букв, от.мечки в|хмснн
изменения файла (несовпадаете временем не>следнсп модификации г. MS I х )S j
и жестких связен (hard links). Все эти возможности в XTFS реализованы. В пер-
вой версии NTFS не реализованы си.мш ынческпс связи (.symbolic links) Р< )S1X, по
в будущем возможны соответствующие расши|хтп1я.
1.2.6 Сменные диски
NTFS предназначена для рабочы каке постоянными, так и со сменными дисками.
Поскольку FAT является стандартом де факао для гибких дисков, Microsoft Ис
планирует поддерживать для них XTFS. Однако, XTFS можно нс полый жать на
друтнх типах с менных носителей, таких как диски Ьсрпуллп. Windows NT это
ОС, обеспечивавиная .laminvor hccuhki тонирование л о дос ту па, н NTFS раепро
страняст эту запилу па файлы. Таким образом, сменные диски, отформатиро-
ванные для XTFS, защищены чемп же механизмами кон троля доступа, чг<> и по-
стоянные диски.
ГЛАВА 2
МОДЕЛИ NTFS
Несмотря па новые требования к восстанашиваемости и контролю доступа, а
также множество новых свойств, введенных в NITS разработчиками, первым и
самым главным требованием было создание надежной и быстрой ФС. Опа дол-
жна была поддержи ван. стандартные операции, такие как загрузка системы и
исполняемых модулей, а также а игнорироваться в многоуровневую модель за-
гружаемых драйверов, определяемую системой ввода-вывода Windows NT. При
этом производительность ее должна была быть такой же или выше, чем произ-
водительность существующих ФС для персональных компьютеров. Для дос ти-
жения этой цели в NTFS использовано несколько моделей:
Я* С точки зрения ФС Windows NT, NTFS — эго просто еще одни загру-
женный драйвер, предназначенный для обработки запросов ввода-
вывода. В многоуровневой модели драйверов системы ввода—вывода
NTFS может располагаться над или под другими драйверами.
С другой точки зрения, N ITS — это сложная реляционная база данных,
применяющая новейшие технические дост ижения для протоколирова-
ния и восстановления данных, а также новые возможности, такие как
множественные потоки данных и индексирование ат рибутов файла.
• С т ретьей точки зрения, NTFS участвует в реализации объектной моде-
ли Windows NT, работая с файловыми объектами, защищенными от не-
санкционированного доступа диспетчером объектов Windows NT и си-
стемой контроля доступа.
2.1 Многоуровневая модель драйвера
В Windows NT NTFS и .другие Ф(. — эго загружаемые драйверы. < >пп могут загру-
жаться пли удаляться из <)С по мерс необходимости. Все драйверы работают в
контексте системы ввода-вывода Window's NT и неявно вызываются приложи
ниями, которые используют Win32 или другие API ввода-вывода- Как показано
на рис. 2-1, подсистемы окружения (environment subsystems) Windows NT вызы
вают системные сервисы NT, которые, в свою очередь, отыскивают подходящие
застуженные драйверы и вызывают их.
Драйверы, расположенные на разных уровнях, передают друг друту зап-
росы с помощью диспетчера ввода вывода. Использование диспетчера ввода
вывода в качестве посредника позволяет каждому драйверу сохранять незаг.н-
Рис. 2-1. Компзне-лы системы зес,-о-вывс-аз Wl"<iows N7.
ciimch ri., так что его загрузка пли выгрузки нс в и; er на дру/ие драй; ж i. ’"p -
ме т<их*, драйвер .X ! I S 1од..м>>дс1inw! с тремя другими коми*•iteiriaыц и ” л-
шггельной системы Windows NT, noiciiuutibiMii г. или й части рис. 2- ‘.с г ’р.л*
тесно связаны с Ф<'.
r.’ejn.:ie vcyinxtia 1Н1>ин.ц11ьц:и’1 <io:. file ы-iw, ITS), раздан-, тайный Пеа-
ном -iiippiii ?Bri;.n Andrew), — это тис темный модуль Wind. -ws XT. < >6eee.vl * •—««-
m.iiii !ipoT!.f,:<'.>i!p‘. am:ic операций «апнси па -inef.'. < >п .«i!;iic>>ii;ac: mntay
лжурпа • (log file), к< ;торый иенольз4.ется для n< neraiк чпсни" тема
NTfS после сТ icifi'ie 1ы.
„'IncHi'iinti';- sciiiiri manage! > ;"e> C; <темный ;:< »!ii<иiciiv Veil.
NT, iiainica. 1яый loww Мм. лером ; Те н Miller; и н'ц-чч1счпг.а1«»!|1иГ; iTime-'.i i-”:'
иую n<>,v’.ep'.i-ia i..-!iiinponaiin-.i ды N'l I S н драйнсрог-лрстил <|X1 iii.uonu.;
ры сетевой ФС <4epi еры н pe.iiipci. юрыB, e ФС Windows X i < v;\e тлы-
.C>c'p.p. г :,:-)п!ир.- 'Ванным i]i:nTi:i >. o<o6paa,a:i поеден me i'- iH|V!y;u!i>>iy:<. 1
кын. viiiin! чтение n .« nu ь r- ik i . P. эти?: нс.тал лнсисгчер raua Хк-спеитт'.’’ »* ’*
‘PC eiieiuia.inaii|>> 'a!m:»!i! н1т., ;я1-л йс - :ai< nepiepy р.ирп'альной иамнтц W ,r.
NT. Ee.-in программа лытхк’гся ;Mparii.">cs к части файла, которая не чагр: ж ‘-
ic-iiii. так на:,ывтемый /'*»чиix л.чпа teaclic iniss), дпеиетчер niip'ivuibi
памяти 1‘.ыаын;:ет Х'1 r'S ддм oopaigemin i. .трайксру диска и иодечепиа соде,
1 ".II. .11. .1 I I, к А •ко. ’.’I <их .•;О1.1.’Ю IS KI11II.- “ пионы Wiiuaws ,V; ", ui <1. J ш-ск ,
HlI, ЛI ,ГТЫ ЮЙ 1ЫMl.. .1
Чгение/зогп1~ь
зеркальной;
гама или
тома с
чередавси »исм
облое тс й
ЩСНИН-' 30: КЛ,
диске:
Рис. 2-2. NTFS и взаимодействующие с ней компоненты исполнительной системы Windows NT.
мото файла с диска. Диспетчер клипа оптимизирует дисковый ввод вывод при
помощи с/)е<к1Пв(1 (>п1.1<>менн<>11 мпшен (lazy writer) — набора системных пото-
ков управления, вызывающих диспетчер внртушшггой памяти для сброса содер-
жимого кэша на диск в фоновом режиме (асинхронная заинек на диск).
Взаимоотношения NIT'S с другими компонентами системы (рис. 2—2)
строятся так же, как и для других ФС, поддерживаемых Windows NT: FAT, HPFS
и сетевых ФС. Единственное отличие состоит в том, что эти ФС не обращаются
к сервису журнала транзакций для протоколирования последних.
2.2 Модели реляционной базы данных
и обработки транзакций
11рограммное обеспечение баз .тайных предназначено для того, чтобы отбирать
информацию на основании произвольной» количества критериев пли их ком-
бинаций. Наиболее мощные пакеты баз данных способны обрабат ывать крайне
сложные запросы и обновлять базы данных с высокой скоростью.
Файловую систему можно рассматривать как разновидность базы данных,
к которой приложения и утилиты обращаются за информацией о файлах. На-
пример, команда MS-DOS/Лт или команда POSIX Is обращаются к соответству-
ющим ФСдля получения списка имен файлов и подкаталогов в данном каталоге.
Обычно “запрос” к ФС требует подобрать имена ерайлов, удовлетворяющих
некоторому критерию. Структурируя NTFS как базу данных, ее разработчики
ОСНОВЫ ФАЙЛОВОЙ СИСТЕМЫ NTFS
( могли воспользоиаткя такими преимуществами баз данных, как си< >< win -.-(
легко отбирать файлы по заданном; атрибуту или возможность сохра1-.„т.,
такие наборы файлов г, виде индексов для ускорения выборки.
Другая черта .дизайна N'1'FS, также тесно связанная с темой баз данных,
что использование модели обработки транзакций для заннси изменений _<
()бработка транзакций — эт< > такой сп< >соб обновления базы данных, при гс.-|-,.
ром сбои системы не нарушают корректное! к или целостность базы. (>сн<
принцип обработки 1раизакций состоит в том, что имеются некоторые о . -д-
инн над базой данных, называемые транзакциями (transaeiions), когорт-
нолияются но принцип; “все или ничего”. ( Ущельные обновления диска, с<
ляющпе транзакцию, должны выполняться (atomically); г. с. если ;
закция начала выполняться, то все ее операции должны быть завершены В
случае, когда исполнение транзакции прерывается из-за сбоя системы, та 1
। pai 1зак1 (пн, которая уже была вы> юлi ici Ki, д< >лж1 ia бы ть <ггметiciia, т.е. д< ыже;< д,
выполнен aimaim (roll back). Операция отката возвращает базу данных в пре. -; i,,v-
щее целостное ссхтоянпе, как если бы транзакция и нс начинала исполнял т
Предположим, что клиент банка перевод! п JaliO со сберегатель! к >г< • • чпз
па чековый счет при помощи банкомата. Он .задаст параметры операции г
вода, и программное обеспечение базы данных начинает обрабатывать з?,;:.- <,
вычитая #5<)() со сберегательного счета. Теперь допустим, что произошла ;ь.-;р-ы
системы из за сбоя питания. Если бы не не пользовал иск принципы обработки
транзакций и после включения компьютера база данных осталась бы в сищ-'.я-
।iniI, не.'к>средетве1 пк> iцтедшеегыжавшем сбои >, т<»iia сбсдх'гатслык»м счет»•<
лось бы па $.МИ) меньше, чем было, но на чековом счете ничего не прибзвил- „л.
61,1. Очевидно, что такою рода сбои недопустимы для программного обеес.с ге-
ния, связанного с финансами.
Рассматривая операцию перевода денег как атомарную транзакцию, , :р>-
грам.мное обеспечение обработки транзакций гарантирует, что весь набор
/(операций снятие с одного счета и помещение па друюй выполняете;-! как
одна операция. Если в середине этой транзакции произойдет сбой системы, т<»
программное <хает печение обработки транзакций, ко'нцхч- вело запис ь вы..- з-
няющихся транзакций и того, пастаыько они продвинулись, .можетотменил,
полненный лишь наполовину перевод, начислив деньги па сберегательный "з-’Т
клиента, после того как система будет вновь запущена.
NTFS использует модель обработки транзакций для носстаиовлспия '• б.
Если программа инициировала операцию ввода -вывода, которая памеилст
структуру ФС (меняет структуру каталогов, увеличивас! размер файла, выл.е.к...'!'
место для нового файла и тд.), то Vl’i 'S рассма тривае т т акую операцию как
мирную транзакцию. Гарантируется, что л ибо та кая 1равзакция будет занср';---
либо, в случае отказа системы во время се выполнения, будет выполнен
1 федположпм, например, что полыювате.ш, создаст файл и M I S вегактяс'г .ш
имя файла в свою тару кору каталогов псиои|К*дсгвснпо перед аварией снетс кч
Запись в катал! яс существует, но щхк транство па диске для файла не выделеш •
()6работка сожития фанта как атомарной операции гарант ирхсг, что NTFS -;т. -
“база данных”) сохраняет г.пу трспнюю пс.аосгносгь. В данном примере N i l s :1’-
кати г операцию создания файла, х'далнв имя файла из структуры каталог,.>н.
Ni ll’s отс.леаашас'г со,(ержпм< >е в >.ма в рсляцпопи< >й базе данных таб.тпкб
содержащей ряды .ыпнеей и кчгюнкн атриоуток Ряды ..laauaii файносп!/ т»<йк.;:-
Utu {master tile table, MF'l j, как называются эта оаза данных, < оотисгствуют отдедч'
Глава 2. Модели NTFS
Рис. 2-3. Записи. Файлов и «сполотое ь главной файловой таС'иое.
ным файлам на лиске, а колонки — атрибутам файлов. Каталог paec.\;ai ривас гея
как файл с песка 1ька иным пабо|к>м атрибудчс На рис. 2—5 изображена логичес-
кая структура МЕТ и различные атрибуты, которые может нмс-п. файл ii.’iii кагалм.
Вместо то;ч> чтобы раеема’1 пикать файл как хранилище двоичных пли
текстовых данных, модель NTFS рассматривай! его как набор атрибутов., одни
из которых — .я<» данные, содержащиеся в файле. Структура рс ля ш юн поп
базы данных позволяет легко расширять ФС. Если пользователь созлас! файл,
то NTT’S просю ззиолинсч новый ряд в таблице. Если программа добщстяег
атрибут-' или I'.iopon по'юк данных, иля cc. ii! файлу присваиваете я альтерна-
тивное имя для MS-IK)S (см, гл. ~), то NTFS вставляет в МЕТ новую колонку для
данного файла, как показано на рис. 2 4.
Как и многие другие реляционные базы данных, NTFS ,чоя;с1 {•••здавл'п.
индексы для атрпбх тов. 15 файл» ня >й системе индекс (index) :-по набор файлов.,
выбранных по значению некоторого атрибута. Например, (диалог NTFS это
индекс имин файлов, имеющих в качестве префикса заданный путь. Bnyi решic
NTFS можс! создать индекс по любому атрибуту, который описан как ипдек< пру
емый, но в настоящее щюмя индексируются только имена файлов NTFS <_op ти-
рует индексы и,мен <|>айзог. при помощи эЦирсктнвпой структуры данных ио,"
названием <1е/«ч>о, г. коюрой имена упорядочиваются лексикографически,
что позволяет oeviHCCTivisri ь быстрый поиск’ ни загцютлм типа dir sir''.
Nora NTFS и использует частично модель реляционной балы данных, она
отклоняется от ./той моде.чн, когда последняя нс- с< jotbctctiivci задачам файло-
вой ciicieMi.i. I laiipiiMcp, NTFS .чолжна реализовывать иерархическую егрукрру
кл'1 азотов, аналогичную используемой ГАГ и HIT’S. Добавляя каталоги в МГГ и
’ К luciOMito.’ в|к-яя .11;.’иы-гы, oiipi ю мыс ibt’iioorcrion-.M. в Vi unions i\i г и,* по,гк'|>жнв.1м)Ю1 <
пако Kiiur.iH :i|!.<im i;iyr>a iio:iiio.ibi~i в fii iyn(e.i и" । 1 |и-
Стандартная Имя Дескриптор
информация файла защиты
Данные
Расширенные
атрибуты
HPFS
Рис. 2-4. Добавление атрибутов и потоков данных к записи MFT.
рассматривая их как файлы, NTFS создаст иерархическую структуру внутри
традиционной табличной структуры (эсляционпой базы данных. Как показан'1
на рис. 2-3 и 2—I, вместо атрибута данных запись для каталога содержит три
атрибута, при помощи которых реализован индекс имен файлов каталога.
2.3 Объектная модель
NTFS участвует в реализации обтсктной модели Windows NT, представляя фай-
лы как объекты. Это обеспечивает совместное использование файлов разик.'*11
процессами и защиту их диспетчером объектов — компонентом Windows VI.
управляющим всеми объектами уровня компонентов исполнительной системы-
Приложение осуществляет создание и доступ к файлу так же, как и к дрУ"
гим объектам Windows N’I: при помощи описателей объектов. К тому времен**-
как запрос на ввод-вывод достигает NTFS, диспетчер объектов и система конт-
роля прав доступа W indows N’I’ уже проверили, что вызывающий процесс имсС*
право на тот доступ к файловому’ объекту, который он пытается осуществит*'-
Система контроля доступа сравнивает маркер доступа вызывающего потока У**'
равлеиия с записями в списке кон троля дост упа файлового объекта (информ**'
цшо о списках контроля доступа см. “Основы Windows \Т", гл. 3). Кроме и>><’-
диспетчер ввода вывода преобразует описатель объекта в указатель на файло-
вый объект. NTFS нс пользует информацию из файлового объекта для досттн**
к файлу па диске.
На рис. 2 -5 показаны структуры данных, связывающие объектную архи-
тектуру в оисратвпой памяти со структурой ФС па диске.
При вызове NTFS передается указатель на файловый объект. Опа прохо-
дит по нескольким указателям, чтобы перейти от файлового объекта к место
положению файла па диске. Как показано па рис. 2—5, файловый объект, пред-
ставляющий одиночное обращение к системному сервису открытия файла,
указывает па а'юк уирачченпя потокам (stream control block, SCB) для (файло-
вого атрибута, который вызывающая программа пытается читать или записы-
вать. На рис. 2-5 некий процесс открыл и атрибут данных, и пользовательский
атрибут файла. SCB представляет отдельные атрибуты файла и содержит ин-
формацию о том, как найти копкрегпый ат рибут внутри файла. Все SCB файла
Рис. 2-5. Поиск файла NTFS.
указывакл па общею структуру данных, называемую au>h<ai уирча lenuu ф.
(file control block, Г'СВ). Последний содержит указатель (фактически файл ’
ссылку) на запись данного файла u MFT па диске.
Как упоминалось г. разд. 2.2, NTFS рассматривает файл как набор ат;-.|
гон. Аналогичным образом, и диспетчер объектов Windows \Т рассчат;
объект как набор атрибутов. NTFS использует одну и ту же подпрограмму у.,
пня, независимо оттого, какой атрибут файла < чптыкастея: данные, дсскр!:.- •
защиты, имя файла ii.ni какой-либо другой. Аналогично, при записи п файл г<
принимает атрибут как параметр п выполняет запись г. указанный arpii. --.-i. ; -,к
скольку эти подпрограммы файловот обьекта являются универсальны.
легко можно нрпспособпгь к работе с л.руигми aipnoy i"imh, которые r
быть .добавлены в будущем.
ГЛАВА 3
СТРУКТУРА ФАЙЛОВОЙ
СИСТЕМЫ
В гл. 2 описаны программные модели, па которых заимствовали разработчики
ФС при iipocKiupiистин NITS. Данная глава оставляет :>in модели в стороне и
углубляется в де i а.и i реализации NTFS, уделяя особ» >< внимание струкнре ФС па
диске и некоторым используемым,тля се поддержания структурам данных, Глава
начинается с обзора понятии и терминов, после чею рассматривав-тся важней-
шие структуры данных N TFS. Далее описывает»/я, как NTFS хранит .данные, вклю-
чая индексы имен файлов, па диске. В последнем разделе рассмаа pi шлются фай-
лы, используемые для управления диском и для вос< тановлеиня.
3.1 Понятия и термины NTFS
Структура NTFS начинается с тчиа (volume).'1<<м соотвстет в\ст логическому раз-
делу на диске и создастся, когда Вы форматируете диск или член, его для N IT'S.
Возможно также создание отказоустойчивой) тома, занимающего несколько дис-
ков, при помощи Администратора дисков (Windows NT Disk Administrator).
На одном диске может находиться один пли несколько томов. NTFS обра-
батывает каждый том независимо « л дрхтих. Примеры конфигурации для жест-
кого диска 15(1 Мбайт приведены на рис. 5—1.
Том состоит из ряда файлов и свободного пространства, <x’iauiiici»x я в
данном разделе диска. ВФС КАТ и HPFS том содержи) также области, специально
отформатированные для использования ФС. Том NITS, однако, хранит вселяй
Рис. 3-1. Примеры ко) kJ шурации ди:.-о.
Г-'.
(оО Мбойй -г *
D:
(9G Мбай|) ,^r-~ j
•\ Г?/ |
ные Ф<:, такие как битовые карты, каталоги и даже системный загрузчик в i .<„
обычных файлов.
NT1S наш on шлет файл»жук< систему Г VI тем, что обе они пенс-льзу» -т _I;i
стер как < -спорную единицу распределения диск- >в< >г» ир<-страиетва. Размер д,.
стера на томе, пли кластерныймнчлс’ипе.т t cluster Factor) уетацаг-лнвастст
литой Format NTFS, когда н< хтьз-житель форматирует том. Кластерный мн- М|
тсль зависит от размера тома, по в любом случае является целым числом ф
ческих секторов и степенью 2 I сектор, 2 сектора, I сектора, S сски>|>ои и т •
как показано на рис. ? -2. Кластерный множитель выражается количеством
топ в кластере, например, 512 байт, 1 Кбайт или 2 КбаГп.
Рис. 3-2. Секторы и клостер на диске.
Внутри себя NTFS работает только с кластерами и не обращает внимания
на размер секп>ра. В отлпч!ic от HPFS, которая требует i iciюльзоваш ы 512 -бай-
тового физического сектора в качестве единицы распрсдслсння пространсгва,
NTFS использует кластер как единицу распределения, чтобы сохранить ис.<:,ч>-
симость от размеров физического сектора. Это позволяет NTFS эффективно
работать с очень большими дисками, используя больший размер кластера, a так-
же поддерживать нестандартные диски, размер сектора у которых отличен • *<
512 байт. На томе объемом ООО Мбайт или более, например, использование раз-
мера кластера, превышающего 512 байт, может сократить фрагментацию к ус-
корить выделение свтхбодпого пространства, за счет небольшого проигры;?а г-
объеме используемого пространства. Утилита Format NTFS автома тически опре-
деляет подходящий размер кластера, однако администратор системы может
изменит ь это значение* 1.
В NTFS физическое местоположение на диске задается при помощи /'••.*<'•/-
ческого номера класте[х1 (logical cluster number, LCN). l.C.N получаются просто
при нумерации всех кластеров от начала тома до сто конца. Чтобы прсобрж'->-
1 Утилита K-irniar ii- ii- i.-ii, iycr размер кластера. равный 512 байт шли ра :мср мшара шоп - сектора,
если он больше чем 512 байт| для дисков объемом до 512 Мбайт. Дш ihx-и.ших дисков, размсро-'
1 Гоапт, iiiTio.-n-rnenи рз :мер кластера 1 Кбайт. Ды дисков -ихьемом 01 1 до 2 loai'n егилпта иси<
.-ует размер кластера, равный 2 Кбайт. Гели о»5'ы*м диска iipeiiijinaer 2 Гбайт, то упиниа естапаыик1-
ег размер KiacTcpa, равный I кбайт. Эта -|юрмула и-т-волясг cixuiaiicupoBini, ес-кствеишк- tipouiBo-
речис межах -рратментаци-'й диска, ктлмран может возиикаат, при е.-нпикг-м малом ра*1МС]Х' кла- те. *
и иенсиоль вемы.м /пи ковым про- -граи-твом (внутренняя фрагментация), iimcioiiihm мест при
--..цинком большом размс|Х- iviacTcpa.
вать I .GN и физический ад,тес на диске, его нужно умножить на кластерный мно-
житель, и результате чег< > получается физическое смещение в байтах, как требует
шперфспс дискового драйвера.
В разд. 2.2 описано, что NTFS поддерживает файл. называемый главной
файловой таблицей (МЕГ), который является сердцевиной структуры тома NTFS.
Логически МFT содержит по одному ряду для каждого файла тома, включая ряд
для самой себя. Кроме МЕГ, каждый том NTFS содержит загрузочный файл (он
описан ниже) и набор файлов, содержащих информацию, называемую .чеша-
данными (metadata), которая используется дчя реализации структуры ФС. (><
гальные файлы па томе N i l's это обычные пользовательские смайлы и катало-
ги, как показано на рис. 3-3-
Рис. 3-3. Записи метаданных NTFS и пользовательских данных в MFT.
MFT реализована в виде массива файловых записей. “Ряд” МЕГ представля-
ет один файл па диске, состоящий обычно из одной файловой записи. Однако,
если у файла много атрибутов или он сильно фрагментирован, то может потре-
боваться более одной файловой записи. В этом случае первая .запись, в которой
хранятся местоположения остальных, называется базовой файловой записью
(base file record).
Файл на томе NTFS идентифицируется б-|-разрядным значением, называ-
емым файловой ссылкой (file reference). Файловая ссылка состоит из номера
файла и номера послсдовате.п.ности. Номер файла соответствует позиции его
файловой записи в МЕГ минус 1 (или позиции базовой файловой записи минус
1, если файл использует более одной записи). Номер последовательности в фай-
ловой ссылке увеличивается всякий раз, когда /тайная позиция в МЕГ использу-
ется повторно, что позволяет NTFS выполнять внутренние проверки целостно-
сти. Структура файловой ссылки изображена на рис. 3-4.
63 47 _______________________ О
Номер последовательности Номер файла
Рис. 3-4. Файловая ссылка.
Раисе файл NITS был определен как набор ачрнбхтон, включая aipiOv,_
имя файла, атрибут -дескриптор защиты и атрибут- данные. NTFS обозначает;.к
рнбу г сто именем, записанным прописными буквами, перед которым стоит
доллара <>): например, x/Z/./jV. LI//? или S7H7.L i )днак>> па самом деле :-хтп н.-д-: ..
атрибутов соотептвуют числовым кодам типа. которые NTFS использует,^
упорядочения атрибутов внутри файловой .записи. На рис. 3- S показана bu’i.i.-
Ml’Тиля небольшого фниа.
Каждый атрибут хранится в файле как отдельный поток байтов. Стр.: ,
говоря, NTFS не выполняет чтения и записи <|>айлов она читает и запиты
потоки, соответствующие атрибутам. Возм<>жиы следующие операции над а:::,,,
бутами: создание, удаление, ч тение i. iuana'i. >на бапт< >в) и запись > дпапа.'я и к:
тов). Операции чтения и .’.аннси обычно работают над безымянным зтриб-,- ,..
данных файла. Однако, мож! ю указать другой атрибут данных при помощи ; п
таксиса именованных потоков данных !с.м. рис. 2- -I).
Структура тома NTFS onpc.ic.iaci лая файлов набор стандартных зтотб.-.
тов. Эти системные атрибуты имеют фиксир «ванные имейл и коды тина, i: ,;v
мат их значений определяется X IT'S. Атрибуты перечислены г таб.-t. А- । -;;с
порядке, в каком они следуют и файлов< «и занпсн, хотя необязательно д. ы i-ay—
го файла должны присутствовать все атрибуты.
Таблица 3-1. Стандартные атрибуты файлов и ка-алат.в
Системный стриоут OnHCt>»ie
Стандарт) шч
инф» -рчапия
t ’.ппсок атрибуте >|!
11мя файла
.тт.риг ;р защиты
Данные
“MS i и >S”-:itрцбутнilKfiLia 'толькочтение,чтение зяпп. ь ч
Дрз; i/nu-nai времени, вкиичая время создания ii.hi и .л?:-
ней модшГ-ш.ашнг. число каталок» , ссылающихся и;, дан-
ный файл, или ; чеч’чш: чтеонкнл теплей thar.l <:Ы-; -.-< .....
Синеок атрибутов, из которых состоит файл. и фай.юваа
ссылка па файловую запись МН. н которой расы де.жсп л:;:-
дый и s атрпбу те-). .ню, редко игшежттемчй атрибут п, ;.e-'i-
ctbwt, если файлу неопх< ущ.-.ю б<нее <>.ih> щ закис.! МГ:‘
Имя файла и символах ( NICOI JE 'Райл можс; имет ь
сколько атрибутов имен файла, что имеет мссп шч: нал i
чин женкой связи К >S1\ к данному файлу или если у фай
ла есп. liKie.MuTHMo'Ki: сгенс|тнро|,.аш!с>е “коро-:кос днл",...
'. >ри;<< >жс‘| me MS-IX iS и !о-ра;;ря.тиой Kepcn’i Win;!-
Структура даено?, защиты, нре,>ю\р«нвио11:ая файл л i.cc..
пионироыипв ЯТ Joi !у !1;|. Утрпбут- .11 : !.рНН !Ор :.;|Щ1ГП ‘
ределясТ. кто .ia.-ic.-ici файла в кто имеет.;:*. iyi; u.--i
<'oAcp:i.i!.Miie файла В м ITS \ файла нс. •. ме-лчашно ген. о, > 1
безымянный атрпбу') данных, и оц может иметь jo;i. .лгч-
те.н.ныс нменованпые атрибуты ;анн.> \ .таким образ» ч, -
файла может бы л> несколько н< пиков данных*.. У кат*ал1
ист а трибута данных' ио у.ч< ciuaiuiio, по о I м. •.ат л ж.-п» i. ’
юязатеды пж. 11 м-.т ь. .pai шые a - pi юуты да) u ii-ix
Кореи!-. ин (С1.са, Гон атрибута, исиол>.. уечые .: ы пплы-сои имен р; " <
размещение ни tci.x а. г. больших катал, тал
с-нтоиа;. карта
;т< >.1ькг. ,чля катале! i >н
Расширенные aipn-
буты ПРО, hi крор
мани»раеширенны ч
ЛГрЦо/гоц ПРО
Два атрноута, используемые для реализации расшипеины --
атрибутов llPI'S.vw подсистемы t >S. 2 и (>>• 2-клнеитов
.раня серверов \Х intioM s NT.
Глава 3. Структура файловой системы
ГланноР фиилоср «сзС'Ли;.. i
Стандартная Имя. Дескриптор
информация файла защиты Данные
Рис. 3-5. Запись мм для небо/.ыгсгс файла.
3.2 Структура на диске
Как было показано на предыдущих рисунках, ряды (файловые записи) MI-T
отвечают Фаниям па томе NIT'S, а колонки а, грибу щм файдов Вея информа-
ция файда хргпнтя в его атрибутах, и таким обр;с >м, ряды н котонки МЕГ
описывают всю информацию, хранящуюся ин томе NIT'S. Размер файловых за-
писей МЕГ для тома — минимум ] Кбайт и максимум I Кба.’п оирс кляется
во время сто форматирования.
Атрибуты файла к записях МЕГ распол> >жсчы в порядке возрастания чис-
ловых значений кодов типа, причем некоторые типы атрибута- могут ветре
чаться в записи более одной> раза; например, если у файла с<ть 1П.ч;к<»льк<атри-
бутов данных или neciaщько имен. 11:: рис. A S показаны атрибуты. к<m >рысобя-
зательны для кажд< и о файла; атрибут стандартной информации. атг’.ну, гпмип;
файла,а грибут дескриптора защит ы и атрибут данных. В .-auitcn Ml ( м<>ту г 1чтре-
паться и другие атрибуты, если они необходимы для данной; трайла.
Каждый атрибут н файловой записи имеет имя <i!co6i!3;rtc.ii,.-i< о и зиа>,с
нис. Имена используяm я во< иот.ном с атрпб<г.1мн данных .тля идентификации
второго пин третыпо потока данных в файде. Значение атрибута at,- поток
байтов, составляющих его. 11апример, значение, атрибута iHLENAME — это им.-:
файла; значение атрибута М >ЛТА это произвольный набор байтов, юхрлщ-::
пых пользователем в этом файле. ;|.тя маленького файла все ею атрибуты и их
значения • например,.тайные файла» умещаются вфайлеиюй лапнен. Если иначе
пне атрибута хранится п< посред.етвсшк> в Ml Г, он называется ci4.:
])иоу/пчч jrc.siilcnt aitrihtitc). i ila рис. вес атрибуты резидентные.>
В начале каждою атрибута расположен стандартный затодслюк, с'одержа-
nuni 1111<|юрмицню о данном атрибуте, которую N IT’S использует для стаёщарт
пой обработки всех типов атрибутов. Заголовок, который всеош является резк.-
деитиы.м, содержит пнф >рмацнь > о тот», яцляется .ли атрибут резпде1ггпым и ти
। ic| »ез1!де» m 1ым. В с.лу час ре.-в )ДС1 пт к их > a »pi к>\ га зап >.-к >в< >к < < >лерЖ| ггтакже е ле-
Дескриптор
защиты Данные
Стандартная Имя
РЕЗИДЕНТНЫЙ
Смещение; 8b
Длина 14b
»г—м ч ?1 |И» I .Л'
'MYFILE.DAT"
[7~Д Заголовок атрибута
| | Значение атрибута
Рис. 3-6 Заголовок и значение резидентного атрибута.
щение значения атрибута относительно заголовка н длину э того значения, к;ц;
показано на рис. 3-0 для атрибута—имени файла.
Если значение атрибута хранится непосредственно в MIT, время, неон ;о-
димое NTFS для доегупа к нему, значительно сокращается. Вместо того, чтобы
искать файл в таблице и затем считывать цепочку кластеров для поиска данных
файла (как это делается, например, в файловой системе FAT). NTFS обращае м я к
диску только одни раз и немедленно считывает данные.
Атрибуты небольшого каталога, подобно атрибутам небольшого файла,
.могут быть резидент ными в МП’, как показано па рис. 3-”- В случае небольшой»
каталога атрибут корня индекса содержит индекс файловых ссылок для файлов
и подкаталогов.
Стандартная Имя Дескриптор Корень
информация файла защиты индекса
индекс файлов
И. Г2, (3,...
Рис. 3-7. Файловая запись MFT для небольшого каталога.
Конечно, многие файлы и каталоги не удастся вшенуть в запись Mi l
структуру данных размером 1, 2 или I Кбайт. Если некоторый ат рибут, напри
мер. атрибут данных файла, слишком велик, чтобы помест ит ься в файловую за-
пись MFT, то NTFS выделяет на диске область размером 2 Кбайт-, отделенную- •,т
MFT. В этой области, называемой отрезкам (пит), или .зкететнам (extent), хра-
нится значение атрибута (например, данные файла). Если затем размер значе-
ния атрибута увеличивается (допустим, если пользователь дописывает к конлу
файла новые данные), то для дополнительных данных NTFS выделяет еще
отрезок. Атрибуты, значения которых хранятся нс в MFT, а в отрезках, называв >'
ся нерезидентными атрибутами (nonresident attributes). ФС определяет, являет-
ся Л1 f данный атрибут pe3i v(ciптiы.м i ьти 11ерезидс‘1 и ным; способ размещш«пя да< *'
пых прозрачен для программы, осуществляющей доступ к ним
- i Кбайт, ec.ui ра «чер кластера ран» н I Коайт
(лава 3. Структура файловой системы
Расширенные
Стандартная Имя Дескриптор
информация файла защиты
Данные
атрибуты
HPFS
Донные
Донные
Рис. 3-8. Файловая запись MFT для большого файла с двумя отрезками донных.
В случае нерезидентного атрибута, такого, каким должен быть атрибут дан
них большого файла, его заголовок содержит информацию, необходимую NTFS
дам поиска значения атрибута на диске. На рис. 3 - 8 изображен нерезидентный
атрибут данных, хранящийся и двух отрезках.
Только те из стандартных атрибутов, размер которых может возрастать,
бывают нерезидентными. Для файла такие атрибут ы это дескрип тор зашиты,
данные, список атрибутов (не показан па рис. 3-8) и расширенные атрибуты
HPFS. Атрибуты стандартной информации и имени файла всегда (х-зидепт пыс.
Большой каталог также .может иметь нерезидентные атрибуты (или части
атрибутов), как показано на рис. 3—0. В этом примере в файловой записи MFT
недостаточт ю места для xpai 1сния индекса файлов, составляя шигх этот б< тльшой
каталог. Часть индекса хранится в атрибуте корня индекса, а его остаток нахо-
дится в нерезидентных отрезках, называемых индексными буферами (index
buffers). Атрибуты корня индекса, размещения индекса и битовой карты показа-
ны здесь упрощенно (более подробно они описаны ниже). Атрибуты стандарт-
ной информации и имени файла всегда резидентные. Заголовок и, по крайней
мере, часть значения атрибута корпя индекса для каталогов также резидентные.
В том случае, когда атрибуты файла (или каталога) не умещаются в МП’ и
требуется выделение дополнительною пространства, NTFS отслеживает эти от-
резки при помощи ви/ннуан,ны.х начерое. кластеров (virtual < lusters numbers,
VCN). Логические номера кластеров (I.CN), описанные в разделе VI, представля-
ют послсдоватслыкмть кластеров всего тома от U до н: VCN же нумеруют от и до
т кластеры, принадлежащие данному файлу. 1(апример, кластеры в отрезках для
нерезидентного атрибута данных нумеруются, как показало на рис. 3- 11J-
Стандартная Имя Дескриптор Корень Размещение Битовая
информация файла защиты индекса индекса карта
индекс файлов
file4 file8
filel file2 file3 Ate5 file6
Рис. 3-9. Файловая запись MFT для большою каталога с нерезидентным индексом
имен файлов.
nuuu ч'М1'|/\оьОИ СИСI ЕМБГNT I S
Стандартная Имя Дескриптор
информация файла защиты Данные
Рис. 3-10. Виртуальные номера кластеров (vC*C- для нерезидент нега з'рибуто д.:о
Если бы :-иот файл ззннмггт более двух отрезкея;, то нумерация чтч'л
отрезка начиналась бы с VC.X S. Как покачано на рис. 5 ! I, заголовок атри-'-
данных содержит отображение н LCX для обоих отрезки!;, чп• н*л-:
NTFS легко находить .тайные на диске.
На рис. 5-11 показаны отрезки данных, по к .другие атрибуты тоже г.
.храниться к отрезках, если для их размещения г, МЕГ недостаточно мести «й'а ••
некоторого файла гак много атрибутов, что они не тмепглкпея в запись ME ",
для хранения дополнительных атрибутов (паи их кв’оловков, в слтчае нс!
дегп ных атрибутов) используется вторая запись МЕГ. В .-лом случае к файле д'-ож.-
лястся атрибут, называемый списком атрибутов, который мы видели в гай.;. ,
Синеок атрибутов содержит имя п код тина для каждого и.-, атрибутов (ранда,
же файловую ссылку па запись МЕГ, в которой нзхощпх'я данный атрибут. ...
бут синеок атрибутов предназначен для тех < лучаев, когда файл сганоыпеи лл;.>:
болыннм ilth так силык> фрагментированным, чгоодщ щ записи МГГ уже не i ’ л;
точно .для хранения множесп'.а отображений \С\-1.С\, необходимых для ... иска
всех отрезков «райлз. NTF5 гпиь редко бывает ис<исходим твн атрибут, чт>. i 'ж.-
nvioci, написать с пениальные программ;.!, 11|Х71назначсн11Ыс пск/почин-лы:.’ ,'".я
тестирования ее кода, работ л к нцеГо со списками атрнбут. ш
Стандартная Имя Дескриптор
Рис. 3-11. СЛсйра.кенио VC*<—_СТ<я нерезидентного атрибую донных
1588 1539
Глава 3. Структура файловой системы
3.3 Индексация имен файлов
Каталог в NTFS это up >сто индекс имен файлов, г. е. напор их имен (с соответ -
ствующнмн файя<>вы.мп ссылками), организованный особым си<к.<н«>м для уско-
рения доступа.,1фая создания каталога NTFS индексирует атрибуты имена файлов
из этого катало! а. Запись МЬТ.-щя корневого каталога тома показана на рис. -4— 12.
Концептуально запись Mi l дня каталога содержит н споем атрибуте корпя
индекса (ПСортирог.аннын список файлов каталога. < >дпако для больших ката
логов имена 'файлов на самом .челе хранятся в индексных буферах — отрезках
размером 2 Кбайт или равных размеру кластера (г> зависимости от того. чю
больше). Индексные буферы реализуют структуру данных !>- дешеви (!>• Нес»,
что минимизирует количество обращений к диску при поиске данного файла,
особенно в случае больших каталогов. Атрибут корпя индекса содержит первый
уровень структуры Ь+ дерево и указывает на индексные буферы. содержащие
следующий уровень. Атрибут размещения индекса отображает VC.N отрезков
индексных буферов в J.C.N, которые указывангг местоположение индексных бу-
феров на диске.
На рис 5 12 в атрибуте корпя индекса и в индексных буферах показаны
только имена файлов (например,///еб), но каждая шшкь индекса содержи г так-
же файловую ссылку на запись MFT, описывающую данный файл, плюс отметку
времени н информацию о размере файла. NTFS копирует отметку времени н
размер из записи М FT для файла. Такой подход, используемый файловыми сис-
темами FAT, UPFSii NTFS, требует записи обновленной ииЦюрмацнн is два места.
Однако при этом существенно ускоряется щхжмотр каталогов, поскольку фай-
ловая система может отобразить временные отметки и размеры файлов, ис от-
крывая каждый файл каталога.
Атрибут размещения индексов содержит отображение VCN I.CN дчя ин-
дексных 6vt|x-[X)B, а битовая Kapia используется дчя отслеживания того, какие
VCN в индексных буферах заняты, а какие свободны. На рис. 5- 12 па каждый
VCN, т.е. на каждый кластер, прим щнгся но одной записи для файла, но па сам* >м
деле кластер содсрж)и несколько записей. Каждый индексный буфер ра тмср>.м
Рис. 3-12. Индекс имен фойлоя для кзо f яо ногалогл гомо.
2 Кбайт может е<,держагь около 16 записей для имел файлов (3 пли I на класт-.ч,
в случае 612-байтового кластера).
Структура данных Ь* дерево (она используется н в ! IFFS) это разног-:
тлеть сбалансированного дерева, идеальная для организации сортирован:,
данных, хранящихся на диске, гак как позволяет минимизировать колпчесл ,
обращений к диску при поиске заданного элемента. В МЕГ атрибут корня нндеа.
са для каталога содержит несколько имен файлов, выступающих в качестве- ;зи
дексов для второго уровня Ь+ дерева. С каждым именем файла в атрибуте к<
индекса связан пеобязачельиый указатель индексного буфера. Этот индекс кущ
буфер содержит имена файлов, которые меньше данного имени с точки зре- .ия
лексикографии. Например, на рис. 3-12 Jilefi - этоэлемепг первого уровня ц-
дерсва. Он указывает па индексный буфер, содержащий н.мена <|книгов, к< >чорыс
меньше (лексикографически), чем имя в этом элементе - fileii, filel и fileA.
Хранение имен файлов в витс В+ дерева даст несколько преимуществ.
Поиск в каталоге выполняется быстрее, гак как имена файлов xpaiгятся в < >т<.о;>-
чнроваипом порядке. 11 когда программное обеспечение более* высокого у р< ч;ия
перечисляет файлы в каталоге, NTFS возвращает уже отсортированные имена.
Наконец, поскольку Ь+ дерево имеет тенденцию к росту в ширину, а не в глубину,
то скорост ь поиска не уменьшается с ростом размера каталога.
В настоящее время NTFS индексирует только атрибут ы- имена файлов, ио
новые версии этой файловой системы могут позволить приложениям как нм-
дить новые атрибуты, гак и индексировать их. Например, если в качестве атри-
бута добавить имя автора, то NTFS могла бы поддерживать b-ь деревья файлов,
упорядоченные по именам авторов.
Файлы метаданных NTFS и загрузочный файл
Все данные i ia томе NTFS xpai штся в файлах, включая структуры данных, ист к ыь-
зуемые для поиска и считывания файлов, данные начального загрузчика и 6iно-
вую карту, содержащую информацию о распределении пространства на и-мг
(метаданные NTFS). Хранение всего в виде файлов облегчает ФС поиск и управ-
ление данными, а доступ к каждому отдельному* файлу может быть ограничен
посредством дескриптора защиты. Кроме того, в случае повреждения участка
диска NTFS может переместить файлы метаданных, п информация на диске г >-
прежнему будет доступной.
Как говорилось выше, в MFT имеется запись для каждого файла на диске,
включая запись для самой себя. Файловая запись MFT содержит либо все атрибу-
ты данного фай.ча, либо отображения VCN—LCN, которые определяют, где на
диске расположены значения нерезидентных атрибутов файла. Расположение’
файловых записей MFT для файлов метаданных NTFS показано па рис. 3-15-
При первом обращении к тому NTFS должна cwninmfxmcnnb (mount) ег< •
т. е. подготовить том к использованию. Чтобы смонтировать том, NTFS nine'1’
загрузочный файл (он описан ниже), чтобы определить физический адрес М! '
на диске. Первой записью в таблице является файловая запись для самой М1’Г-
Вторая запись счхлиетстнует файлу, находящемуся к середине диска и содержа-
щему копию первых 1(» рядов MFT. Эта неполная копня МЕТ используется дл”
поиска файлов метаданных в том случае, если часть файла MFT по какой- лн'«>
причине нельзя считать.
Глава 3. струн i ура щсилсво
ICJIVICI
После того как файловая записьдля МКГ найдена, NTFS считывает ипфор
мацпю отображения VCN I.CN дня се атрибута данных, распаковывает эту ин-
формацию и сохраияегес в памяти. Данная информация < вторит NTFS, где на лис-
ке находятся отрезки, госта паяющие MFT. Затем NTFS paci 1акс шываст записи MFT
еще для i к‘ск< >льких файле >в мсгадщ u них 1 г открывает э'и i файлы. Далее NTFS вьп и ът-
няет операцию постановления ФС (описана в разд. 1.3) н, наконец, открывает < к -
тавшпсся <|х|плы метаданных. Пёперь том готов к использованию.
В процессе работы NTFS записывает информацию в еще один важный
файл метаданных журнал транзакций (log file). В журнале транзакций ре-
гистрируются все операции, влияющие на структуру тома, включая создание
файла и любые команды, такие как Сору, изменяющие структуру каталогов.
Журнал транзакций применяется дая восстановления тома NTFS после сбоя
системы.
Еще одна запись МЕГ зарезервп|х>вана для корневого каталога (известного
также как Эта запись содержи т индекс файлов и каталогов, хранящихся в
корне структуры каталогов NTFS. Получив первый запрос па открытие некото-
рого файла, NTFS начинает поиск этого файла с файловой записи корневого
каталога. После того как файл открыт, NTFS запоминает его файловую ссылку,
чтобы при последующих операциях ввода-вывода обращаться к записи МЕТ
этого файла напрямую.
Схема распределения пространства на томе хранится NTFS г. фай:ц- бито-
вой карты (bitmap file). Атрибут данных этого файла содержи! битовую карту,
каждый бит которой представляет один кластер тома и указывает, свободен ли
данный кластер или занят' некоторым файлом.
Другой важный системный файл —загрузочный ipaii’i (hoot file), в котором
хранится код начального загрузчика Windows NT. Для того ч тобы можно было
загрезнть Оскол начальной загрузки должен располагаться в определенном ме-
сте диска. < )Д|>ако при <|юрматированин утилита Format определяет эту область
как файл, создавая для псе файловую запись, благодаря созданию загрузочного
ФайлО
1
2
3
4
5
6
7
б
16
МП
Копия MFT (неполная)
Файл журнала транзакций
Фойл тома
Таблица определения атрибутов
Корневой каталог
Файлы
метаданных
NTFS
Файл битовой карты
«1>айл плохих клаглеров
Пт.лкжео’елоскнс дэи-чы и каталоги
Рис. 3-13. , зс.,.уложение- г Г , . <;ч:й':.ьдх . э' о-й ,v фаи.'ог! магаданцы* NE 3
файла XTI’s может приасрживатыя своего правили рассматривать все, иах>у-й
щссся па Томс, как файлы. Загрузочный файл, как и файлы мстаданны'- Х'рх
H.MCCI отдельную защиту при помощи дескрипторов защиты, к< л’орые црг.ч-.-щ-
мы к любым объектам Windows XT. .Модель “все, что иаходитса па диске,
файл" означает также, что начальный загрузчик можн, • мо.щ|ф1щнр<,вать
обычных операций файлового ввода—вывода, хозя в настоящее время за;-;-
пый файл защчщеп от [к-дакгироваппя
N ITS чакже но/щерж!и.ает фай! шахт' кшсше/ин; (bail cluster file-
Гис-грации всех точек повреждения тома и (fiuii.i пиши (volume file), со.:
щий имя тома, версию N IT’S, для ыггорой он <т|>орма;и|у>1.ан, и опт, к<-Т;
бу.дучн установлен, стпи.-1изи}П’ет, чп> юдержныое тома пс.ирегичено с; <
но бып> неправлено угнлпгой <7nkdsk (см, разд. S.S}. Наконец, имеете" Т
содержащий niciniifitv “H/ieih’.ieHHii ai>i[>n6yiU‘>t{ (attiihute tk inii'.ion ?ahle..
рая задаеч тины атрибутов, поддерживаемые на iomc, и сказывает, м< •и-н-, - (v
нидскснровать, восстаиа.-лннат;. операцией восстановления «.нстемы •;
ГЛАВА 4
ВОССТАНАВЛИВАЕМОСТЬ
Наиболее нажав sc umtis; N’ITS - >то, пееомп :пю, ее си- «л >• «н» >еть i; ?:«.ч'ст.1-
imwioii» > luv.'ic еб< ><>.. В< iceianaicшн аем« кть ФС , ирантируст, чт< е.тучас-
за питания или фатапьн.>Л Л1сгем.ч«>й ciuiioi.e ин одна >• ..чералия ФС : ipauaai?
цня) не останст< я незавершен!!’«й, а стр. i.«ypa nncia>!« ; т« -ма пуде: с< «хранена,
н при этом не нридс’к я прибегать к утилите неправд . ним диска1. В’я.станаиглша
емость NTFS повышает общую надежно; п. Windows NT из благо корпоратив
пых польз-«кителей и a.pvntx «кииса .натслей г i •>!<. < жичн требованиями. В суши’ >-
СТИ, csiocoOHo. та к ьоссгитшлепню ФС >. Windows NT ;t;->cii!>nii;i«.i тот уровень
надежности, за который расе нтыи; мт сейчас корпораи-вныс по-Нонкате ш,
причем :<т« я’ «олиптсльиый уровень стабильности л«>ети1 аеня NTFS за счет
лишь itc3iKi'iir:v.!binw> > нриш рыш.а в.р<'ч!.-.г,о .ите.н.кмегн. СносэСл; hti- i. г.и<-
становлении > - непременное 1рсгйшзпис для при.:: ъкений, о5р:1пап..1!.а*чцн.х
транзакции, а также зля ере ють iiictei.cantni атрибутов.
Восстли;|г..1л1;.-|смосгь реализована i. NTIS при номошн схемы .-курий, я
транзакций. Эта ( гра:еп:я гарантирует н<ы>кч* i<oc<-r'liiorjief-nc ihcici, к> пч -р< >е,
кстати, вып< !.1ияет<•.>чсиь 6ыет|>«> (к течение i екун.-ь лаже ,vbi елл>:..х Г*» 1ьпн:х
дш ко:;. 11)т >цсд\р.ы ы >сстано леиия \Ti?b па<. нрое:ранмюц'я лишь на даииые фай
ловой ciKTv.-.u.i, глрантруя,1 зь н> ыыи ятсль, и< > крайней мерс, 1;!нз ч да i >с ti:
нн пся все;-, -зома па—за п< жреждеинй ФС. < Хлиакч - полное w ч\ ганок, си hi н« •ль.'и .-
вательскпх данных . случае аварии сиетсчы не гараи гнрусгея. Гешо.мс он.азать-
ся оз восстл! 1о=:ления шыь'яя^ггслы.'кнх файдов — это результат к<>миро'>вг<.а
между н< >Я1и»сгыоо'п.л:р лс'Н’йчикой сисземе.й н такой, которая < «бесиечлнает.эи-
тпма-'н.ную' ||р!нгшодителыи»г1ь ды всех oiicpa.’uifi с файлами. Визета неимение
польз! !нате.'11>с1;и.\ файлов можс: быть реализовано как растнрснпс NTFS.
В верном pa.vic.ac да!пк»й главы описывается эно-поння належав >сти •!’<', в
вэтом KoiricKcic |»г.|ынгся 1«к ст1Иа1С1пгаемая ФС. В<> втором разделе подробно
обсу.к-г.1гзся схема iipoioiai.inpor.aiiiia транзакций, при помощи которой V! 1S
регветрирус! и вменения сгрукпр данных ФС, а третий раздел «изъясняет, как
NTFS шн'стапавлнваетт«»м вся',час сбоя сноемы.
1 I» .Х’П;> И.МСС1СЯ VTitHM'ia ChkcUk, которую мохно и, и<»Л1>.кя.-.т> /(.ля и< прзпченим -гефеигок диска,
вьинашилх ошибки ми вводз вывод.! : например, плохими секторами пи тио-е, .•>лек'гр-1г-рт1си‘»и .ню-
и:*л1Г»ми или е'боями диска » либо иртрамликио обеспечения. И»» not кольну у NTFS «*< н> pt ‘ 'твл
Boccriiioi-.-iciinH, Chkvbk использус1*'--1 редко
ОСНОВЫ ФАЙЛОВОЙ СИСТЕМЫ NTFS
4.1 Эволюция файловых систем
Создание шюетшкнешнасмой ФС можно рассма грнвать kii; еще < >днн пкп г
люцни ФС. До настоящего времени были известны два основных тюдхо
организации поддержки ввода вывода и кэширования для ФС пючиап :i,.
(careful im/ei и иптмепшв! :;апись (lazy write). В ФС. разработанных для -Чд
VMS фирмы I Mgital Equipment Corp< nation и не которых npyi их (>С, исподы.
ся алгоритм точной записи, в то время как i; OS.2 11PES и большинстве ФС Г.
применялась схема отложенной :ишк в.
Файловые системы точной и отложенной записи преобладают в ОС in. t v-;„
пальцы." компьютеров, мипикомпьютсров п больших ЭВМ, тогда как воссга...
лпвасмые ФС отпостпслыю новы. До NTFS они использовались в оспоипо.; .
исслсдователы'кпх системах и в некоторых специализированных система.- ; v-.
ального времени либо устойчивых к отказам. Windows NT — одна из uer.x-j
коммерческих ОС, предоставляющих восстанавливаемую ФС.
В следующих двух подразделах кратко рассматриваются два типа фай щ-
вых систем, наиболее распространенные в настоящее время, и присущие ни
противоречия между безопасное) ыо и производительностью. В третьем. <;.Г
разделе описан подход N i l s к восстанавливаемое! и и его отличие от , п •?,
.других стра гсгнй.
4.1.1 Файловые системы с точной записью
В случае аварии (X, или сбоя питания операции ввода- вывода, выполнявши ?.'«
в данный момент, прерываются немедленно и зачастую преждевременно. В за-
висимости от того, какие выполнялось операции ввода - вывода и сколь да.
продвппулось их выполнение, такая внезапная остановка может нарушить нес- т
спюсть ФС. В данном контексте нарушение целостности это поврежл< цис
ФС: например, имя файла появляется в списке каталога, но ФС нс знает, где >н
находится, или не может обратиться к его содержимому. В самых тяжелых с.1 у-
чаях повреждения ФС могут привести к позере всего тома.
Файлс >вые системы с точной записью не пы таются предотвратить пару ге-
ния целостности. Вместо этого они упорядочивают операции записи таким
разом, чао авария системы в худшем случае вызовет предсказуемые, некритичес-
кие нарушения, которые ФС может устранить в любое время.
Когда ФС любого типа полу чает за и рос на обновление содержимого дпе.сг
она должна выполнить несколько подопераций, прежде чем будет заверни’ю
обновление. В ФС. использующей ттратеипо точной записи, эти нодоперз:..-'11
всегда записываются па диск последовательно. При выделении дискового пр."
странства, например, для файла, ФС вначале устанавливает некоторые биты «'•
оптовой карче, после чего выделяет- место для файла. Если сбой питания пролг-
хо/пгг сраз\ же после того, как были установлены биты, го ФС точной запе.д;
теряет досту 11 к некоторой части диска пространству, представленному уста-
новленными би гами, — но i упкттву кнцне данные нс разрушаются.
Упорядочение < шераций записи означает также, что ззпр< >сы на ввод —
вод выполняются в порядке их поступления. 1;слн один процесс выде;|яег,ти< i. ”
г.ос просчрансчтю, и вскоре после этого другой процесс соз,чаеч <|»айя, п»фай_. >'
пая система i чч>чн< >й записью завершаег выделение дне кош >г<> пр< хтранетва Л*’
I/XOEVJ *-*. ronv-iDrП
того, как начнет создавать файл, иначе перекрытие подопераций из дву х защх<-
сов ввода-вывода может привести к нарушению цслоспioc'iн2.
i ктювпое преимущество <I><; с точной записью состоит в том, что и случае
сбоя гом остается целостным п его можно использовать дальше, не прибегая
медленно работающей утилите исправления тома. Такая утилита необходима
для исправления п|Х.-дскэзус.мых, нс разрушительных нарушений целостности
диска, которые возникли в результате сбоя, но ее можно запустить в хдобное
вре.мя. обычно при перезагрузке системы.
4.1.2 Файловые системы с отложенной записью
Файловая система с точной записью жертвует производительностью ради на-
дежности. Файловая сис тема с отложенной записью повышает производитель-
ность при помощи стратегии кэширования “Цюпоная запись” (write—back); ины
ми словами, изменения файла записываются в кэш, и содержимое последней > сбра-
сывается на диск оп тимизированным способом, обычно в фоновом режиме* 1.
Улучшение производительности, связанное с техникой кэширования “от-
ложенная запись”, лсктшаенся несколькими путями. Во -первых, уменьшается об-
щее количество операций записи па диск. Поскольку нс требуется упорядочен-
ных, немедленно осуществляемых операций вывода, содержимое буфера може т
измениться несколько раз, прежде чем будет записано па диск. Во-вторых, рез-
ко возрастает скорость обслуживания запросов приложений, поскольку Ф(: мо-
жег вернуть управление вызывающей программе, не ожидая завершения записи
на диск. Наконец, стратегия отложенной записи игнорирует промежуточные
состояния с нарушением целостности тома, возникающие тогда, когда нес коль-
ко запросов на ввод-вывод перекрываются во времени. Это облегчает создание
многопоточной ФС, допускающей одновременное выполнение нескольких опе-
раций ввода—вывода.
Недостаток метода отложенной записи состоит в том, что при его исполь-
зовании бывают периоды времени, в течение которых нарушения целостности
тома слишком велики, чтобы ФС могла их исправить. Следователь!ю, ФС с? отло-
женной записью должны постоянно отслеживать состояние том a. HPFS, напри-
мер, устанавливает на эти периоды времени бит, называемый битчи изменений
(dirty hit), чтобы подчеркнуть, что целостность тома нарушена. Если сбой опера-
ционной системы произошел в то время, когда том был измененным, его необ-
ходимо восстановить при помощи утилиты исправления тома Chkdsk. Факт
чески, пос кольку в общем случае неизвестно, была ли целостность тома па са
мом деле нарушена в момент аварии, Chkdsk следует запускать после кажд<>1
перезагрузки, при которой установлен бит изменений. Время, требуемое на вех
становление тома IIPFS, зависит от сто размера и от того, сколь большим по
врежтеииям с»и подвергся.
1 Файловая cnclvua 1 AT MS—IX >S исполюусг а.п" ipirru “сквозной .ташки”, при котором обпогистшм
лаписывактя па диск немедленно. В отличи.- от точной кшиси. техника союзной записи не требу-
ет от <|>С. упорядочения операций вывода для предотвращения нарушений цело, тост
1 В \\ endows NT и PAT, и HITS реализованы как ФС < отложенной чапнсью они uowcutjioi измене
нпя ,im ка в 1.:лн. Диспетчер юша, в с вою очередь, использует схему отложенной .laiincii .для синими
зацнн вывода на диск для всех ФС Windows NT.
Хотя в процессе исправления диска целостность тома всегда •ю-.чта-кщщ
кается, (результаты исправления нс всегда устраивают пользователя. Напри-.-. -.
утилита С1 ik-J.sk HIT'S иногда не ,м< -жег определить, к как: -му катал- л у < >тнос, -|,-
вновь созданный файл, и помещает его в улавливающий вес каталог ‘Ьц.- -
lie. hi г<-м был серьезно поврежден, т- > может случиться, чт< > нею -т- >рыс фай ж.. п,
\ дается косе та нежить и они будут up- -сто потеряны. В < иянем елу чае. отл- -ж< ..н; 4
запись дает выигрыш в ирон::г-од1пглы1< чти до сравнению с точи: -й занн. кд,
за счет большего риска и неудобств дня пользователя при с-х-е системы.
3 Восстанавливаемые файловые системы
Воес1“1пан.11:васмая ФС, как предполагается. долила превзойти но падежи- ,ц -
ФС с точной лашк'ыо и достичь при этом пр- -|зг,одител1.|икти ФС с --г.-',, ।
ной записью. ФС такого i ина гарантирует с- -хранение не. кепи к hi тома: с >г
целью используется техн: >л< -гни ве/юипя журнала изменений, разраб:-тан-гж- • : .
воиачальпо для обработки i paiixn.iinn. В еяу час аварии < X'. такая Ф<во;.г'т;-'
лпваст целостность при н< -моши процедуры носст.и кишения, которая не:к •т. т
информацию из i|xuL-ia журнала транзакций. 1ак как Ф<' регистрирует за:;,!--'л н
диск в ж\ риале, то восст anol vic пне занимает несколько сскуи г иг зависший
размера г--ма.
П|юце.|.ура носе тан- -iciei iiim в N ITS является ’ючн-.-и ii гарантии' .ст а-;
щеннс гоми к ।|ск-ггоромх >е.вкTII- чг. с<итч>я;ин--.-. 11га.кгкнап-.ые ре.-ельга'." ; г-
сгановленш!, характерные’ для <1x1 е от.-южепп--й записью, в X IT'S иск. 1юч;-- т i.
За ныс- -кун - падежи:ять -мч стана-с-нваемой ФС при»>;,-н.-'ся расплачи:,л
ея. При каждой транзакции, и сменяв -щей структур- тома, требуете;'. занетал
одной записи па каждую подоперацию в журих* гранзахпий. ФС снижает ,-н.
накладные расходы на iip-Tc-Ko-iiipmiaitiie.-a счеа -иил-.-шненця записей ;,
транзакций в i.ai.CTi-i — -а одну -щерацни- ив--да-вывоза г. zi-урна.л добаз.-г.>.
сразу несколько ’.а1шссй. Хроме -юго. гюсстапавливасмия Фц может ирнмсн"' ..
приемы оптимизации, которые используипся <1>С с отложенной заинсь-- . - а
даже можеч увеличить интервалы между сбросами кэша ни шек, гак как Ф-‘. ж-
но !«кттаи-ови ! ь, если авария произошла до того, как пзченення из кэша был.,
персиисацы па диск. Такой р< хт пр >пзв< >дн'сс.-1Ы1ости кэша not равнению с ьк.
сотложсшюй записью ком пепси рус г и часто даже- персы шнвае! накладные
ходы, связанные с пр<поколир- -влппем транзакций.
Ни точная, пи отложенная naiuxi- не гарантпрук-г зашиты польз:-ва'.т..,.
скнх данных. Если сбой системы произошел в тот момент. ia-гда приложение
выполняло запись г. файл, го иос.1гдний может быть noie;»iii или разру- .си.
Болес -юго, сбой может повредить <1>< ; с ог.юженпой записью, разрмние. суще-
ствующие файлы пли даже сделав вею информацию па томе нсдог'|у1той.
X ITS исиользуе: стратегию, у.п-uiiaioiuxio ее 11ялсЖ1 ю: ть ио сравнению .
чрадпцноппы.ми ФС. Во-первых, восстанавливаемость NTI S гараптирчет, что
структура тома не будет разрушена, г:и; что г. случае сбоя <-исгемы все файл
• ктанутся ,-1.ост\ иными.
Во- вторых, хотя в н:н”гоящее время KITS Ис гарантирует сохранности
иользог.аге.льскпх данных г.случаееб<-я гппемы пек:гр »рыс изменения г,к:; е
Могут бып> потеряны, при.-южения могут воспользоваться преимуществам!'
сквозной записи и сбух-еа кэша N 11’S для гарантии 'юго, что нзменеиня фай.:;-
будут записаны па диск в положенные .моменты времени. II сксмишя
(cache write -trough) принуд) псльная немедленная запись на диск >. «иерацпй с
файлом, и сб/нн K^niiit (cache Hushing) - принудительная зашит, на диск содер-
жимою кяша вполне .->ф<|»ектиг.иы. NTFS не гребуетт.я дополнительного ино-
да-вывода для сброса на диск изменений нескольких различных структур тан
пых ФС.так как изменения rrpvKivp данных [Х-тнетрнруются к:рн иом> >щн един-
ственной операции 3ui:Hcn) г. а»урналс транзакций; если произошел сбой и со
дсржимое кита потеряно, т<» изменения ФС могут быгь висела'«•г-.тены ио ин-
формант! ил журнала. Волес roio, NTFS, в от.тпчпе от HI'FS и FAT, гарантирует,
чт! > сразу п< ic.ic . ч:е|>а!1!н> ci. озн. «и записи или сброса к:-япа данные иолы,..! ,.т<
ля сохранят нс.юстп< >егь и будут доступны, даже если вслед, за зтим нр( .пз« .йлет
сбой системы.
И наконец, г. XTFS заложен фунламеш для нчц чтобы г; будущем г.ве
ели поддержку иротоьт пирования транзакции для пользовательских фаилое.
Вместо протоколирования транзакций для н<«л1«ювате.><д.т:ч.х .данных гм
пользователи, которым нужна лонолппильная степень влдюыз.-етн, х »гут
применять ! fl Sisk драйвер отказоустойчивого диска Windows X Г ,.v
создания »• поддержки xpaniu>i!iii.a данных с 1>збь;т-»ч:в.стью i.iiim иттсль-
iivH» информацию об нзпь!ц-.Ч|1«ч'"1! данных см. г. гз. S “Управление п>*.’.амн
и <»ткаы 'уст* inч i । в*. >стъ”)
4.2 Протоколирование транзакций
Воестаплвлнкас.мость ФС • NTFs '.бсспсчивзется при 1ю.м.ш;н техники обра-
ботки транзакций, называемо ! н/ччн^к^ 1Ц;ин<-:ьнлч dogging;. В npiHeccc* u; i-
ток<хтпр<-ва;п!.ч, прежде чем выпи'.нить нал СиДс-рж. ьмым «ьска к:ь.ую -лип*»
подоперацию |ранз.|К1'ии, •.'.зменяю'цей важные структуры фай.; •'зли сие.’:-ты,
NTFS тайне ыг.ает се . <| ай-i хурпата транзакций. Гасим «браво, t, ... случае сбоя
системы незасер!>!спсые грапззкцпп мо.сно вчт. -рг.ть шчпнпь после
перстагречки машины. В NTFS >гф;11;:н1к:ын Transaction) о:jjч-де.«ена как оиер’-
цпя ввода- вы.юда, на. ен !ощ;'ч данные ФС или пгрущуру ката.. т> "'а. Нтп
операции, к ке,т« .ры\1 ; ->тн нттгея. I! час । к:и~!тлжнись на ,,-;сх il l!.' у.га-.ст!<;е фай-
ла, .могут сая то._ть из нгско. ti-fctx :.т доП'Сранз'й.
Л состав с ред>'ris np<>roi;« •лирог.аи1'я X Ггх 1с<--дя.. х ч>мг"- пенса:
Собс’Пи.-НН- >. : i’/ л I ; log (ilc ) ц . н;-|3д з,т/ Hd'ic: 'Jug !ьс
sen ice, I.FS). 'кбриил транзакций .-*то системный -.['ай.:, создам тзый колки св >й
Formal,:! ’. FS - наборсцстсмпы:-. npoiie.iyp, которые-NTl-.s . ’ ньг.зуетл. 1м досту-
па к журнату транзакций. ’ Пделеши? I.FS тг ФС низы лит другсо: слог'.-.'.н'ыт.
KOMHuiiciira 1 >i.!ii будушнм прп-ожепиям создавать собетг-енпыс зурна. :ы д.<
ре:ь!’1зац!П! во{т"|':наг.,;!!вае.-.:о;.“:,п на уровне прикладной пр зраммы, как :--!Т-
яелж г.я i: епетсм;-х < -браб: тки гранзактшй.
4.2.1 Сервис журнала транзакций
Хотя LI’S разраб! ..тан, чтобы .- ях-спечить средства цроток« щ1|>ог,ання и ьос<' т,
не >1ыепп>1 «я иес чем для < >. ui< я< > клиента, перк< >нача,тып > он д« к-тунен т< г:ь><'1—
«1ч i через тине;'Фейсы;>e.>kii.4i!>Ф!>ч (kernel inode inierfnce.s). Вызывающая пр:
г|«а.мма, в данном случае N'i'FS. передает I.FS указатель на открыты!! {рай.вч.ып
o<vi>eicr - <|>апя, который буд<-г нснояьз:шаться как журнал транзакций. I.FS .н. '• •
ин ФлиливОИ СИСТЕМЫ NTFS
Протоколирование г Диспетчер
Вызов диспетчера виртуальной
памтпи для доступа
к спроецированному файлу
I
Рис. 4-1. Журнал транзакций.
инициализирует новый журнал, либо вызывает диспетчер кэша Windows NT
для доступа «существующему журналу через кэш, как показа! ю на рис. 4-1.
LFS дел ггфайл xypiшла на две часл к оичастърестарта (restart area) i1 “бес-
конечную' оачастъ прошокачированпя (logging area), как показано на рис. I 2.
S ITS вызывает LI'S для чтения и записи области рестарта. В этой об.таси:
NTFS хранит информацию контекста, такую как позиция в области протоколи-
рования, откуда она будет начинать чтение при восстановлении после сбоя си-
стемы. На тот случаи, чт о область рестарта будет разрушена пли станет п< ка-
ким-либо причинам недоступной, I.FS создает ее копию. Остальная часть жу.р
нала транзакции - это область протоколирования, и которой находятся заиис?
транзакции, сюссиечивающие NTFS ык'сгановлсиие тома после сбоя. LFS с< >здаст
иллюзию бесконечности журима транзакций путем его циклического новн л-
ного использования («тоже время гарантируя, что нужная информация нс зу-
де! затерта). Для идентификации записей, помещенных в журнал, LFS использу-
ет камера логический пос. /едоваше. iwtocmi / (logical sequence luimhcr, LSN). Цик-
лически используя журнал, LFS увеличивает значения 1.SN. Число возможных I-SN1
настолько велико, что практически может считаться бесконечным.
N TFS никогда не выполняет чтение запись транзакций г. журнал пан)
муи>. ISN обеспечивает сервисы, которые NTFS вызывает для открытия .рас.
журнала, помещения в журнал записей, считывания закисей из журнала ь >
мом н г. обратном порядке, сброса записей журнала до задашь. ю> LSN или п; ь
двнжения логическою начала журнала на больший LSN. 1! цропетсс восещпюг.
кипя NTFS вызывает LSN дли чтения шпиеей журнала в прямом направят
чтобы повторить все транзакции, которые были запротоколированы в ж\ риале,
во не записаны на диск к моменту сб< >я. N'l FS также обращается к LSN ддя чтеинч
записей и обра тном направлении, чтооы отменить ( или откатит!.) псе q>aiкшю
ЦИ11, которые не были но..нпн“ГЫ1> .•i:iiip<>Toi;o.nipoB:inbi перед аварией систе.'”' ‘
Глава 4. Восстанавливаемость
Область рестарта LFS
“Бесконечная' область протоколирования
Копия 1 Копия 2 Записи журнала
Рис. 4-2. Журнал транзакций
Кроме того, NTFS вызывает LSN для продвижения логического начала журнала
па запись с большим LSN, когда ей становятся не нужны старые записи журнала.
Система обеспечивает восстановление тома следующим образом:
1. Сначала NTFS вызывает LI’S для записи в (кэшированный) файл журнала
любых транзакций, модифицирующих структуру тома.
2. NTFS модифицирует том (также в кэше).
5- Диспетчер кэша вызывает LFS для уведомления о необходимости сбро-
сить журнал транзакций на диск (этот сброс реализуете я 1.FS при помо-
щи обратного вызова диспетчера кэша с указанием страниц памяти, под-
лежащих выводу на диск; см. пос.тсдователы1осп> вызовов на рис. (- 1).
4. Сбросив на диск журнал транзакции, диспетчер кэша записывает на
диск изменения тома (сами т ранзакции').
Эта последовательность действ) in i apai пирует', чт< > если нс удастся выпол-
нить изменения ФС, н> соответствующие транзакции можно будет считать из
журнала п либо повторить, либо отменить в процессе восстановления ФС.
Восстановление ФС начинается автоматически при первом обращении к
тому после перезагрузки маниihi>i. NTFS проверяет, применялись ли к тому тран-
закции, запротоколированные в журнале до сбоя, и если нет, то повторяет их.
NTFS гарантирует также от мену тех транзакций, которые нс были п< >лностыо за-
протоколированы до сбоя, гак что вызванные ими изменения нс появятся на и >ме.
4.2.2 Журнал транзакций
Прежде чем модифицировать том, NTFS обращается к LFS дтя регистр;) пни в
‘журнале любой грзнзакцпн, которая изменит структуру тома. Действуя таким
образом, NIT'S использует технику обеспечения восета на кт нвлс.мостн, извест-
ную н теории обработки транзакций как опережающее кронит-ет/х’ваши’
(write ahead logging).
LFS позволяет cmя; м клиентам помешать в журналы транзакций записи
люб< >п> тина. NTFS :teii« viiaver несколько пив>взаписей, два из к»>r« »рых .«/«л*
си ши фи кацни (update record s н липши контрольной точки «check pains
records) описаны ниже
4-2.2.1 Записи модификации
большинстве ::;<! в teen. которые N IT'S ш «мешает журнал трап:такт и), npejeraiinioT'
co«N >ii записи м» угпфнкацни. Кажта-а такая .здиись с< >Держпт дна bi ща in яр»>р.маии1 с
IhujMp.Mtniu>i Л111 новпк>ра (redo ini’onnationi как вновь применил,.
точу i> un подоперации> полноегы<>з;шр<>т<ил>.т рован нои (“ц< 1дты (с,-
депп- >й”', транзакции, если сбои системы произошел д< > пни, как т
.".акция была переписана из кипа на диск.
/ кчформацнн tX'iJi чинены outdo inibmiaiioH) как устранить nr- ,г,
пня, вызванные одной подоперацией ipanaaKmiii, которая в м-.
сбоя бьыа :-.апротоко.1пр<>i:ntia лишь частично (“не нодтверж,к na"i
На рис. I 5 показаны гр-н з.аппсн m:i;hk|>hk;uihh в журнале трап,"., 1(-.
Каждая запись представляет собой одну подоперации) грапзакпнн, ыелш-
новый файл. Данные повтора в каждой записи сообщают NTFS, как !к..!;- ;)...
применить данную no,io:>epantno к nniy, а данные отмены — как i птатить .<>
нить) но. по.(операцию.
После нро'1око.ч!рог.:1пн.ч транзакции (г-данном i.-римсре, вытыва:! i
помещения i[H x записей чпдифшещпи в журнал тp:uifiii) \ I T’S г.ыне -(че.
се подоперации не’лосрелсгг.енпо над томом .. клик . Ио окончании оСмю _с.
ним к-ш ta N!I?S помещает is журнал еще одну запись, которая помечает i.T; т^. ।
закцию как завершенный. Дта ио.ъ терапия и:мкл тиа как ;ющщ;е/...>ю>ем/1е
М1кцин (coinmininga nansacth>п . 11«клс ни-»как'.•рапзакпвя подтверждена. s
таpaiпирует, что все кытнлвпые ею модификации буд\ । отражены па т. д.'гл гкс
сС.'Ш после подтверждения произойдет i бой 'И’.
При в<кттaitoiviC!>uii после сбоя системы Х'1'FS просматривает ж1.о ;
иовторяс с все подтвержденные трзизак-иии. .Даже если X'l'FS и .йш ри!.т; п
дикцию до момент сбоя системы, ей цещи-жспю, бы.п! лн изменено, :.т. -
сврсменно треп пса иы на Д1К к диспетчером к:-члл. М<-ц крика; ц;и, вы; :
ныс в к.-лпс, люс.тн быть потеряны при с-мч.-. О< дователыю, ,\1 ?-х вып<
гверлуасиную транзакции = с и;п;:=, да-'ы fapaiггнр- .а л., чт,> mci: нах.>ди;о. it:. -
злы |< >м -л чтс «1Н11 и.
После поит, -р;: всех 1;1снтержлениых траизаглий >« I'rS отыекивает .. жур-
нале такие, которые нс был;.- нс•.тдкдткдецы к mi >мснту ?ч, н откатывает . т,-е
наст) каждую .^inpirroKo.шри>ванн\ю иыдоцврацн'’ d c.iv-iac, п.-дюраз.е.ию.м
рис. 4-3, \'['!'ь вначале должна была бы отмени и. i >,тонера!нш»’Г!,. ;« .... •? ч-.г !
перейти по указа гелю вазах и огменнть Ti !iep« .хи,: i. > у..а:, а гелям ;• ебг.м- п ,<м
на правят ши и отщ-на т >д< .нсринин нр> v>i .джались бы д< > ; ех пор, ;пж.:. N'l’FS ; с
Отмена: т долить ичс Фойле из индекса
Рис. 4-3. З'г *.. » ‘ ь / vs- Т.»ин-ки<цкм.
достигла бы Нерпой подоперации транзакции. Двигаясь по указателям, N Г18 мо
жс“гон] кде. п1ть, сколько и какие затки модификации нужно отменить. !, ы того,
чтобы откатить транзакцию.
1 Imp' >рма!;.и.ч tin попг<>pa и < iT.mci 1Ы м< м:ет быть выраже!ia .’iinч > :|цi.,.гич -
ки, лiioo.i' я’ическп. Фпзвчсске.< шислнне задаст жгпир;iKaiuiii те»ма ж. к днщia
зоны бан; на .упеке, которые следует изменить, цере.-кч'тгг'л» и т.л, .hничсс.м?
описание и|Ч7£стаа.1яе1' м< MiiiiptiKaiuri 1; терминах терапий, например “удалит;,
файл A.1JAT” Будучи самым ни.жпм урог.пе.м ирос'ра.м-.щог. обеепе’.енля, |,<ч-
.цержнпающим структуру ФС, NTFS используетзаписи moji.'lJ лка-пн! с физ.' .сс
Кими описаниями, i >анако;г<я щюграчхнюго! гбеслечелня ; л'работки трапзак
цпй и драгие приложений жнак и мо/иариканве и jt..-п теске. вне < .»у« б i,
удобтice, но< к>i.ii-.kv. в :Гкчсс1з ч* iцч*.;стак ,е; ч в* чг. -н.тетш т*.. .a ic? мпакт; .ч* фч i-
знчсскнх. .Логическое •ruieanne г иеобх.-дпм.н'тыо s. i.’.aiamv на X ! ’ S i, ikhhi-
Maiiiii I Ti и7 *, ч го именно ьь: :н>. тяк • г такие i я u*j»a!!!..;, ка. ’ у, ta.’iei i . с фа; иы
NTI'S rencpH[>vs.T.'.;i-:iiep м<;у:нф':сз1.;1>1 н>:.... ьч ; >ип,.).1ы.1>!; чя ка с.к гй из
следу loiiiiix грл>«акций.
с<i.i.taiiiJc файла
удаление файла
pac;;iH|X*i inc фзн.-ти
урезание .ранда
vc’iiu и.-ька Фай.то! »п ннформзнии
ucps ч: ie< к„’.аи11г ф;; s' 1ла
изменение npai; .u.ciyii'a к файлу
Пц<|1орм;|>г>|>! ДТП ilC.BT;>p.i И отмен - И заки-. н I-ir'all.ili! До I.-hlHl б-Ь,.’»
тщательно позобрана, потому чю ирп .тменетраь. e i, п. г< чт таichii;. >е-
лс сбоя сис'л. мы !ыи даже и \о.к н<.•р.ча.ка.ой раб сп '>'i I S ьвкет
повторить Tpai;3:iKn.:uo, которая расе была выно шепа, я.;п. наооср. ;Т, г/гме-иг.'»
транзакцию, которая никогда нс выно/и-ялл ь либо ул.е от.' едена \нз.г.ячin
XrTFS может попытаться повторить н.п; ямепкть i[>aiиссиня>. е< =ст-: ши ю из не-
скольких записей \юТ11ф|1кзц;п1, из которых нс вес бы./н применены к .'плеку.
Формш записей моди‘.|‘ч!ка1цП| .!• i.ia.en i арантировзть. что 11”л;щние опсраи'-в
повтори или >тмеиы бу.дутц<'е.ит>те'<н;.чы.'-in titlemp лен! j.т. с имет • !,е;. ;;\г!ь-
ный эс|х|х.кг: iKiiipiiMcp, устиногжа бига, ксл’О(>ый уже устлновлси, не скачзшас’Т
никакого .действия, но измене ппе на hpothboii« сложи' >е 'я гачен ля бита, кет- |
уже были 1 изменено, < 'Казыг.ает ФС обила: :и также к< юрсклп < < >6; :аб;г1тлг.;г.':> ik рс
ход! 1ыс <. < ic п пн 11 in г< >ма.
442.2.2 Записи контрольной точки
Помимо записей м<•дпфпкацнп, NTI'S периодически помещает в журил.: ’рак-
закцнй .‘.ант ь kohi’jx >'!ьт>й точки, как показано на рис. 4 4.
Запись копг|ю..11.ноп roni.ii помогает X Il'S опре.чеяпгь, какая опраоотка
необходима для BoccTaiioii.-ieHiisi тома, если сбои произошел немедленно после
номещеиня лтой записи к журнал. 1>..таго,1аря информации занвен кош рольной
точки NTFS, например, знает, как далеко назад еп нужно щюйтн по жу риалу, что -
бы начать восеппюплеипс. Д< >6nniir. i к >r.yi< > запись коитро.тын >й и >чкн, NTI-S запп-
Рис. 4-4. Запись контрольной почти в журнале тоонзскций.
сывасг се LSN в слблзсть рестарт, так что, начиная восстановление н<х'.:е -5,^
СНС'ГСхМЫ, она можс г быстр» найти самую последнюю- запись контр >яьн<.-й ;•.л-.,и
Хо тя 1.FS и имитирует для NTFS бесконечность журнала 'транзакций, д.
мом дслсон I if бесконечен. Значительный размер журнала транзакций и --,я
вставка записей контрольной точки (операция, которая обычно освой--ж.тх-т
пространство в файле журнала» делают верой шость его переполнения C:-.i-
точно малой. Чем нс менее LFS учитывает такую возможность, отслежн.- ,те-
сколыл > значс-г и 1й:
размер свободною пространства в журнале,
размер пр ютранства, необходимого для помещения в журнал с ’.е.т-ю-
щей записи и для отмены этого действия, если потребуется;
• размер прхтранства, необходимого для о тката всех активных - i -с н< .-д-
тнержденных) транзакций, если это inn proven я.
Если г. журнале окажется недостаточно места для Суммы последних двух
пунктов, то LFS возвращает ошибку “исрсп< >лнеипс журнала тран.закт нГ. > NTFS
iciiepiтруетпсключстню.(Эбрабслчикисключений NTFSтпкатывасттекущей = т;:ап-
закцию и помещает се в очередь для рестарта через некоторое время.
Чтобы освободить простратк'1 во в журнале транзакций, NTFS должна вре-
менно приостановить ввод -вывод в системе. Дчя этой > она блокирует со.екчзю
и удаление файдов, птх'лс чего запрашиваем’ монопольный доступ ко все'.! от-
крытым файлам. Постепенно активные транзакции либо успешно завершатеня.
либо получают исключение “перст vuiciinc журнала транзакций’'. Последние NTFS
откатывает и помещает в очередь.
Остановив ввод—вывод в системе путем получения монопольного .-.ос-увз
ко всем открытым файлам, NTFS вызываем диспетчер темпа для сброса надш к
еще нс записанных гула данных, в том числе не записанных данных журнала
транзакций. 1(осле того, как все успешно помещено на диск, данные в жур-кие
зранзакций NTFS более не нужны. Опа устанавливае! начало журнала ни 'л.лз-
щую позицию, что делает журнал “пустым”. За тем NTFS перезапускаем’ трин:
нпи, поставленные ранее в <»чс|к-дь. За исключением короткой паузы в обрао- iV~
кс ввода-вывода, ошибка “переполнение журнала транзакций” нс оказывает
яння на ИСПОЛПЯ1ОЩ1ЮСЯ транзакции
Описанный сценарий - это один из ирнмцюв гого, как N TFS испол-луй'’
журткы транзакций не только дня воет та1101ыспия <1х п но и для исправления - -
бок при нормальной район-. Мы вернемся к восстановлению в следу ющем ра:де.--?-
Глава 4. Восстанавливаемость
д З Восстановление
NTFS автоматически выполняет восстановление диска при первом (посте за-
грузки системы) обращении к нему программы. Если иоатлюшипце tie -цилу-
ется, ир< >песс является тривиальным. При восстановлении используются две таб-
лицы, которые NTFS поддерживает в памяти:
ТаСиица траншкц/ш (transaction table) предназначена для отслежи-
вания транзакций, которые были начаты, но еще не подтверждены
Подоперации этих |ранзакт1ИЙ должны быть удалены с лиска в про
цсссс- Носса ановлеиня.
В /дг/нг/др-илмененныхсш/хпшц (dirty page (able) записывается инфор-
мация о том, какие страницы кэша с< >дсржат изменения структуры фай-
ловой системы, еще нс записанные на диск. .')т и данные г. процессе шс-
станонлсния должны быть сброшены па диск'.
Каждые S < скепд NTFS помещает в файл журнала транзакций запись конт-
рольной точки. I (епосрс/ктвстшо перед этим она обращается к LFS для сохране-
ния в журнале текущей копии таблицы транзакций н таблицы измененных < гра-
ниц. Затем NTFS запоминает в записи контрольной точки ESN записей журнала,
содержащих копии таблиц. В начале процесса восстановлен! 1я нос яс сбоя систе-
мы NTFS обращается к LFS для поиска записей журнала т ранзакцнй, содержашпх
самую последнюю запись конт рольной точки и самые последние конин yt-о.мя
нулях выше таблиц. Затем N ITS копирует эти таблицы is намяты
Обычно после последней записи контрольной точки в журнале транзак-
ций находятся еще несколько записей модификации, Эти записи ссхл’Нсп тву ют
обновлениям тома, произопщтшим после того, как запись контрольной точки
была помещена в журнал. NTFS должна обновить таблицу транзакций и таблицу
измененных страниц, включив в них информацию этих дополнительных запи-
сей. После обновления таблиц NTFS использует их, а также содержимое жу риала
транзакций дая обновления собственно тома.
При иоссгаповлеинн тома N IT’S выполняет три прохода но журналу тран-
закций, загружая сю в намяты ia перш >м проходе, чтобы мини тезировать объем
дисковою ввода-вывода. Каждый проход имеет свое1 назначение: анализ; по
втор транзакций; отмена транзакций.
4-3.4 Проход анализа
Во время проходи (iiuLiiiM (analysis pass) NTFS просматривает журнал транзак-
ций в прямом направлении, начиная с последней операции контрольной точки,
с тем чтобы найти записи модификации и обновить скопированные ранее в
память таблицы транзакций и измененных страниц. Обратите внимание (рш.
I 5), что операция контрольной точки помещает в журнал транзакций три
записи, между которыми могут оказаться записи модификации. NTFS должна
начать сканирование с начала операции контрольной точки.
1 Ixiiee подробно диспетчер вирвчыыкяТ памяти Vinsloivs X 1 описан н i.kihv "Основы Win,«>ws Xi".
i-.i. о, “Диспетчер впртуыыюй памяти"
диспетчера киша может начать иереипсыпать содержимое кэша па дпет
Проход анализа
Рис. 4-5.
4.3.3 Проход отмены
Завср,!Н,!'' 1'ро.хо.’ !ювто|.л, Ni l'S начинает отмены (undo pass!, откаты-
вая все транзакции, не нодгнержденные к моменту сбоя системы. Ikt рп< I
показаны две транзакции и журнале; транзакция I была зо.пт.сраучена ди <•'» ..<
сисгемы, а чраизакцпя 2 нет. NTFS должна отменигь трзнзакцн..) 2.
Каждая запись лто.дпфш.ацш.1, расположенная . журнале ::о<-де •_• д ,
операции контр »чьн< -й н.» \н, предстал..—.гт пм’-м исмеценце •ип'м» у л Л-
транзакций, дно.. таблицы и.мгмениых страниц. ! «ацригер. если зато е:» а
фикании - тп -завись “пол тосрждС! ine Tpiiunuri .ин”, нта трш.:.ак>1то;, к -тер
представляет данна.. _аи сь, д>игла•!«. быта удалена и:. •.•айдиды трзнзакцил. .
логично, если запись молифтшши! - это запись "обч< xcieiiue стг-а.п::" ’’. .-
торая изменяет струи ;уру данных ФС. то необ.м viur-io внести точъглт-.-
щуп» нсшравкх в таблицу кзмененны.х страниц.
i 1< к того как таб.-шны и намктн при нелеп hi в актуаяыз >е с-. >С1 - чп • !:', б'
iipoc»Ki ipi:B:iei' их, чтобы -шредддить iSN самой стар. >й записи моднс
регистрируют! и операцию, которая не была гляи.шиена над дне».м. /••'Viu."
транзакции содержит i5:\ неродг-т. -ртоенных ! незавершенных: трап:;; • г,п.'-,
габ.вп;. измененных страниц ISN описей, е'х/гг.егстку1о|цнх модн.рнк; i .i ;. =
кии, которые не б; i.ih переписаны на диск. IS.X fa мой старой заппск, i-;..‘i, .ш
ной N ITS г. этих двух таблицах, определяет. никуда начнется проход ж i.t :ж.
< )дн:иа>, сети последняя запись контрольной точки окаяипти бтг раин--и. то
К'П-’х начинает проход повтор;; с нее.
.3.2 Проход повтора
Ila b’/T-.vo.ie (nil.i pass) MTS сканирует журнал траи.ипспнГ: в пр.........
иапранпснип. начиная -. I.SN < амой старой записи, кот- >рая была обцару'.;;ен;. лк
проходе auadir.ia (рис. 4 -<>). < )на ищет записи “<бн-ч' -енне страпиньГ, с- цс;
.кашне MoiunpiiKamui тома, которые были заир.итокт* >нро|:аны .то сбоя . д.
мы, но не сброшены яч к:-;ша на диск. MTS ;к•втирает .-пн •.(Г>ноктенп.ч i г
Когда MI'S достигает конца журнала ср'.ишакп.нй, сна уже нош
к:-нп необходимыми модификация ми тома, >> средегно о сложен;той л;-, i- г
Проход повтора
С? юрегчаоч не выпслне> «псы над А*4-том onepauris1
Рис. 4-6. 'нх.-ход neb!;4 “
Проход отмены
5оги-.:-'Т;сдтк.д <!дем1Г т^юн: нами
[ I Транзакции 1
[ П Транзакция 2
Рис. 4-7. Проход смен--..
Г1редиол</.К1!?.1 «по 1|х.-пзакцня 2 c.irriai-xLia файл. ' >гл оиераты епегоит из
tjx’x подопераций, н 1с;кдая иг: нн.\ iraecrrciu ж .•запись модификации. Заннси хтохн
фтстли, огн.х яш.песя к унк =й транзакции, связан! в .шрпа.хе нрп ш>м; ядц указа-
телей назад, г мл.олыд они 1ч1ычно не следуют 11спос|ч-.1< и:с1шо о;ша за др,гой.
В |.';!блиие'-рапзак!1пй N TFS/yiH кажюй ие шнсршенпой трапзакиин храшнся
LSN записи модификации, ко;-орая была Помещена журнгеч шнле.шей. В данном
примере тайп пса арлпзакипй vKa.ajiKier, че. огштранзашпин 2 .^s.-annci- •' i>N Р-Ч-с
NTFs выполняет ондп' tpan.iaKiii.4i 2, как показано на рис. I 8 (справа !ia.‘;eiu У.
Каждая laiiuci- моупкрпкаппп содержит информацию щ-ух шцюы как <то-
втарить шуигдерашио и кш: - .тиснить ее. После обнаружения I.SN 4<'i<; NTFS
Отмена: "обалиж :рж<.“ чл'< Mt-
Рис. 4-8. Отглотл :ронлч1т.ии.
находит информацию отмены и выполняет отмену, очищая биты с 5 не. и р
своей битовой карте. Затем XTKS переходит ио указателю назад к I.SN |...|^
который указывает ей удалить повое имя файла из индекса имен файлов.
нсц, NTFS переходит по последнему указателю и освобождает файловую
пись MFT, зарезервированную для данного файла, в соответствии с лнЦ».рЛ|
цнен из записи модификации с LsN |04б. На этом откат транзакции 2
чсп. Если имеются другие незавершенные транзакции, то NTFS повторяв,
же процедуру для их отката. 1Нискольку отмена транзакций изменяет стру; Vpv
ФС на томе, NTFS должна протоколировать операцию отмены в журнале '-’цац!
закцнй В конце концов, во время восстановления может снова произойти гб<^,
питания, п XTFS придется выполни л» повтор операций отмены!
Когда проход отмены завершен, цсл<хтн<мть тома восстановлена5. К
момент XTFS сбрасывает на диск изменения кэша, чтобы гарантировать цра.
biшыюсть содержимого тома. Далее NTFS записывает пустую область рсста|хга
указывающую, что том находится в нормальном состоянии и что, если сисп_-.ма
сразу же: потерпит еще одну аварию, никакого восстановления не потребуется.
На этом восстановление завершается.
NTFS не только применяет журнал транзакций для восстановления тома,
но также использует те преимущества, которые даст протоколирование тран-
закций. ФС. обязательно содержат большое количество кода для обработки
ошибок, возникающих в процессе нормального ввода - вывода. Поскольку XTFS
протоколирует каждую транзакцию, модифицирующую структуру тома, опа
может использовать журнал транзакций для восстановления после ошибок ФС
и, таким образом, сущес твенно упростить код обработки ошибок. Ошибка “пе-
реполнение журнала транзакций”, описанная в разд. 42.2.2, — это один и:; при
мсров использования протоколирования транзакции для обработки ошибок.
Обратите внимание, что большинство ошибок ввода-вывода, получае-
мых программой, не являются ошибками ФС и, таким образом, NTFS не м-кки
их исправить самостоятельно. Например, получив запрос' на создание >,{?jh.i:i,
NTFS может начать с создания файловой записи в MFT, после чего ввести лмя
файла в индекс каталога. Однако при попытке выделит ь по своей бит. .вш!
карте пространство для нового файла она может обнаружить, что диск rtfjx.’-
полнеи и запрос на создание файла нс удастся успешно завершить. В -гом
случае NITS использует информацию журнала транзакций для отмены ркс
выполненной части операции и освобождения структур данных, зарезеры.:*1'
ванных сю для файла. Затем ошибка “диск переполнен” возвращается вы:.!;|
ющей программе, которая и должна предпринять соответствующие дейе :Я
’ STT'S гарантирует, чк> жх'<-гап*и<пс11Ич* верчк-ч чоч к неч.члорому evil и*л овившему ранг;-
ному солччяччию. чч» ччч нбязитеиячо ч; тому, чвгактос нечк>с|ч-длпенно чич-дшесчночча.чо сбою с-д
мч-ч N1TS чче «uyix-ч дачъ тач;ой тарантим, тчк ч-.ц. дчя повышения чччкичшо.ч.чгге.-н.чихти она чи >lh'
ауе'ч а.чпорит-.ч "<хг,-|<ы.ечliloi’o по ствер-.-ч, юши’ ?»;ч.'.х сопит:,. ,ч -это in.i'iin, -по <бр<к ж; рн.м1.1
чакцчш ччз Ч..ЧЧЧЧ.1 чча шск не bi.iii >лняс -я ч вс ценно всякий ч-.ч.ч, чяи-дл добач.чя io; кичись "чр...ч
чакчичч кччче; ячк-чча” Вмело -.аоч., несколько Kiiiii.-cfi ччод1В1-р:ч;.чеччия чраччз.ччз.чш объедччччячок'
н.Ч|Д*1 чч .М11нсч>шакпл| <х>вмеспчо либо чочда. ч.'оч'ча .•икпеч'чч-р чшчча вч»131,ччил U-S дч» :'бчк ..ч -1
II.IJIJ 11.1 ДИСК ЛИОО КО1,|Д O-.IC-lIt.lt-T Н .|ДрН.|Л НО К» t.lllHt-|> !;OU'fpO 4l.ll(>l’l ТОЧКИ 1..1-.КД1.1.* о
КСИД’! До-.Ч-.ЧЛ причин.!, ИО кочорочт Ч<»4 НС чкхтда HO3B|-.;tIIUt-4VH К СЮ.ЧОАЧС 11ОСЛС.ЯК'-чу СО.-1ЯЧЧЧ-" 1
СОС-ЧО1Ч1 ЧЧ чх>е„ что во ЧЧ;Х-МЯ сбоя СЧЧСЧСЧЬЧ .чочуч б|>|-ЧЧ. .1Ч-'Ч1<|1|1Ы исеколч.ко чч.чр:ич1 ЯЧЧЯХ ip.lllt 11
и чч*-кочорч,че ччч кччччччсчТ ччоччк’тж’юччич >ччч\ чр;чиз.ччщ11Й вчячиячкччог перечч|К1.чн,|ччис траччечь-ч чччч . '
,,ИСЧ.-. ,1 lit-ко чрча:* > Ч ; to ЧЧ.Ч [ЧИНЯ после 1И.сС1аНО1.'1еНИЯ 'lot, в ЧЧСЛОСПЧОМ «ОЛОЯИЧЧИ В1ч.ЧЧО‘‘" Ч
чолч.'о чч- ip.iii !.iki;iiii, чьи tail- < ll(Vi “Т' -Ч ' I'l-i siki.iii iii-[ieiinci>iiuiiiit- rpa i.ik< .1111 11.1 1 к
ГЛАВА 5
УПРАВЛЕНИЕ ТОМАМИ
И ОТКАЗОУСТОЙЧИВОСТЬ
Возможности NTFS расширяются, когда опа используется вместе с драйвером
Windows NT под названием FtDisk — драйвером отказоустойчивою диска, кото-
рый разработан Бобом Ринном (Bob Rinne) и .Майком Глассом (Mike Glass). В
многоуровневой схеме драйверов системы ввода-вывода FtDisk располагается
выше драйверов жест кого диска и обеспечивает средства управления томами,
хранение данных с избыточностью и динамическое восстановление данных из
плохих секторов па SCSI (small computer system interlace — системный интер-
фейс небольшого компьютера) дисках.
Хотя FtDisk работает со жемн ФС, поддерживаемыми Windows NT, NTFS,
FAT и HPFS, — в сочетании с NTFS достигается наивысшая степень обеспечения
целостности данных.
NTFS самостоятельно выводит из использования плохие кластеры, когда
FtDisk не установлен в системе, и обеспечивает д:ы дисков, отличных от SCSI, экви-
валент возможностей FtDisk доя восстановления плохих секторов. NTFS также кон-
тролирует и обнаруживает разрушение структур данных ФС и использует FtDisk
для восстановления своих данных, чтобы гарантировать собственную надежность.
В первых двух разделах этой главы описаны возможности управления то-
мами и создания избыточности данных драйвера FtDisk. 'Гретин раздел посвя-
щен дополнительным возможностям NTFS, улучшающим надежность и восст а-
навливаемость дат 1ых.
6.1 Возможности управления томами
Хотя FtDisk и называется отказоустойчивым драйвером, он реализует и Другнс
срсдсгва управления томами, помимо отказоустойчивости. Наборы томов и чере-
дование дисков не обеспечивают избыточности данных, но помогают, соответ-
ственно, в организации томов и п< жышенпи эффективности ввода- вывода.
5.1,1 Наборы томов
//г/бор тайне (volume set) это один логический том, составленный из ряда
(максимально до 32) свободных областей на одном или нескольких дисках.
Системная утилита Disk Administrator составляет из этих областей набор то-
11 тя—ч>лл|/|/\хдвсди СИС I tZIVIDI IM 1
Рис. 5-1. Набор томов.
мов, который затем можно отформатировать для любой из ноддержинае?-
W indows N T ФС. На рис. S i показан набор томов размером loo Мбайт, иле: Аф-
финируемый буквой I):, ксггорып был создан из последней трети первой»
и первой трети второго диска.
Набор томов удобен для объединения небольших областей ег-обо-у и >:« ,?v
кового пространства с целью создать том большсто размера .либо для сиз
одного большого тома из двух или более маленьких дисков. Гели набор том-.,в
отс|х)рмат1!ро1К1Н для N'11-S, го его можно расширить, включив новые свободные
области пли дополнительные диски, без разрешения данных, уже хранящихся ил
нем. Это одно из важнейших преимуществ, коюрые даст описание всех данных,
находящихся на томе NIT'S, как файлов. NIP'S может динамически увелн .и.-члк
размер логического тома, гак как битовая карга, задах’идея распределен;!: • р-
сцмисгва на томе, — .что просто еще один файл. 'hair: бппяюй карты моаз- .
ширить ,для учета пространства. ’(unaivieiiiinn* к тому. С .-(рутой стороны, динами-
ческое расширение тома ЕЛТ и< лребовало бы расшн]кния самой таблицы !>ia...e-
щетшя файлов, что привело бы к смещению всего октального содержимого
l-tDisk скрывает от ФС физическую конфигурацию дисков. N i b’S, на......
мер, рассматривает 1л на pm . S I как обычный Ию - мстабайтный том. NiTS -б-
ращается к своей би говой карге. чтобы определить, как< >е место на то.меси1>5 -Д*
но для размещения данных. Затем опа обращается к l-tDi.sk для чтения или :>лл
си данных с пекото|юго смещения г. байтах от начала тома. 141 risk считае. * и
зпчсскис сектора набора томов последовательно пронумерованными о* iH.pi "
свободной области на первом диске до последней свободной области па
нем дне кс. т )ц опреле.тяс!. какой физический сектор и на каком диске с«ь
ствуетуказанному смещению.
.2 Чередование дисков
Че/нчкхшпие(Ьик(к< (stripe- set ) ото такая организация дисков, г. которой груп-
па разделов (ио одному на .(иск) объединена в один логический Том ути
Disk Administrator. На рис. s 2 показан пример организации дисков с тремя •
делами, каждый и--. которых расположен на одном па трех дщког.. (Раздел и
череде >i*,aiii в 1. (исков нс < -.блзатс.тыь > дс >лже11 занимать i телып д|ick: сдлнс твс< н
ограничение- Состоит в том, что все разделы до.-ькны быть одного размера.;
Для ФС из<.бражек!кю на рисунке чередование дисков выглядит как о/,..-*
том размером (St) Мбайт, однако 1-tDssk оптимизирует для него в|ч-мена з.зг.пг;'
п выборки, раснреде.|яя .тайные*тома Mcaciy фи 1нче< кн.мн .(исками. I ll .'isk раб-
Улова 5. Управление томами hoik зоуст ч ocit>
Рис. 5-2. чередование дисков.
тает с физическими секторами дисков та!», как если бы они были носле.-юва-
тслыю пронумерованы вдоль чередуемых областей ио веем дискам (рис. " 5)
Нискольку каждая чередуемая область занимает всего 64 Кбайт (это зна-
чение выбрано так, чтобы отдельные онераипи чтения записи нс обращались
к двум дискам), данные имеют тенденцию к равномерному расп|х-леленню
между дисками. Таким обратом, чередование увеличивает вероятность нчм, что
несколько одновременно ожидающих выполнения операции ввода вывода
будут обращаться к разным дискам, л тх’кольку к данным па всех трех дисках
можно обратиться одновременно, время задержки при дисковом г.воде- кьня
де часто снижается, особенно в сильно загруженных енскма.х.
Н\л • )ич <их семорс^ пои че:>_дс-. д/зис-е
5.2 Отказоустойчивые тома
Наборы томов делают \та'антенне томами более удобным, а чередование .(ис-
ков распределяет шнрузку ввода вывода между несколькими дисками Однако
.чти .два Ciioiooa управления томами нс «•беепечпнлкп imht-tjiu яслей ня данных
в случае сбоя диска. Для згой цели в rilhsk реализовано три схемы и быт дню;
хранения: зеркальные наГюры, дуплексные напоры и чередование ,ии ков с за-
писью чейlocTTI. 11: .‘.1>.:юва гс in мс’ут сл.ченствова гь :>тн возможиоеги при но-
Moiiiii хгилиты I>isk Adiniuistrator.
ФАЙЛОВОЙ СИСТЕМЫ NTFS
.2.1 Зеркальные наборы
I':чрка iciio.m uadope (mirrot set > содержим' >e pa >де ia на < ушом диске iy-. .ч. ...
стен в p:«:tie.'ie para в ir« > размера на др\ го.м диске. Зеркальный най< >р н:юбра:..<,.!)
на рис. 5 -I.
Когда программа выполняет запись на С:, I !l.4sk записывает те же
данные на го же самое мест» > зеркального раздела. Если первый диск н.п; ..
либо данные па С: станут нед<хтупны.мп ил за аппаратного пап upoi-pa mj.
сбоя, то Ftl>isk автоматически обращается за данными на зеркальный р_:.,*.е>-
Зеркальный набор можно отформатировать .для любой ФС. по.х’щржни.л’.’.р.щ
Windows NT. Драйверы ФС остаются не зависимыми, и на них не оказьч лет
какого влияния зеркальная работа Ftltisk.
Зеркальные наборы способствую г повышению производительности .„ц,.
но загруженных систем. При высокой интенсивности инода—вывода I tI’>Nk ;.;ii
предсляет операции чтения между первичным и зеркальным радиолами -гы_
вая коянчепно ожидающих завершения заи|Юс<>в ввода вывода ыя каждо:о,..;,.
ка). Две операции чтения могут быть обработаны одновременно, и. таким = •« ра-
зом, они теоретически завершаются за половинное время. При модпфш. зщ
файла необходимо произвести запись в оба раздела зеркальною набора, но ;а-
ггнеп на диск выполняются асинхронно, так что дополнительное обног ’ нпе
диска обычно не влияет на произвощ!дельность пользовательских програм к
Рис. 5-4. Зеркальный набор.
С
(зеркальный)
.2.2 Дуплексные наборы
У(}Ч1И’к:слы11 наипр (duplex set) что вариант зеркальною набора, когда аеркачь-
пый раздел находи тся на диске, управляемом другим контроллером. Такая
фигурацпя гарантирует пользовате.зям отказоустойчивых систем, «по :;cpi a-'‘'>-
пыс данные осаану|сяд<>стун11ЫМ11 даже в случае сбоя .[искового контроллера б*
нс пр<х~то сбоя диска).
.2.3 Чередование дисков с записью четности
Чередование дисков с мптсыо чептосши (stripe set with parity) что тойчН'
вый к отказам вариант обычного чередования дисков. йЪказохттойчпвоеть.-у’1-'
тнгается за счет резервирования эквивалента одного диска ,дтя хранения нН"
||х)рмацпн о четности .гая всех чередуемых областей. Чередование дисков с з:е
ппсью четности представлено на рис. 5—5.
Главе 5. Управление томами и отказоустойчив стъ
Как показано па рисунке, информация о четности для чередуемой области 1
хранится на диске ЕОпа п|тсдсгакпяст собой побайтовую логическую сумму (Xt )Ri
первых чередуемых областей иа дисках 2 и ? Информация о четности для чере-
дуемой области 2 хранится на диске 2, а для чередуемой обласги 3 на .диске ?.
Такое циклическое размещение четности подпекам и|хдсгавляет Собой «люсоб
оптимизации ввода—вывода. Всякий раз, когда данные записываются па какой—
либо из дисков, байты четности, соответствующие изменяемым бай гам, должны
быть пересчитаны и перезаписаны. Если бы четность постоянно записывалась
на один н тот же диск, к юн был бы все время занят и moi' бы с тать узки м местом
для ввода-вывода
Восстановление диска после сбоя при чередовании дисков с записью чет-
ности основывается на простом арифметт 1ческом принципе: если в уравнении с
н переменными твсстны значения //— / переменной, то значение оставшейся
можно определить вычитанием. Например, в выражении л + г = г, где .г обозна-
чает чередуемую область с четностью, нужно вычислить2 — г, чтобы определит ь
д'; чтобы найти г, надо вычислить z — х. EtDbk использует сходную логику для
восстановления потерянных данных. Если при чередовании дисков с записью
четности произошли авария диска или.чанные на одном из дисков стали нечита-
емыми, FtDisk реконструирует отсутствующие данные, используя операцию
Х( Ж (побитс>в<>с л< я’пчеекое слс>жш и ie).
В случае сбоя диска 1 на рис. 5-6 содержимое его чередуемых областей
2 н 5 вычисляется путем побайтового логического сложения соответствую-
щих чередуемых областей на диске 3 г областями чет пости на диске 2. Содер-
жимое чередуемых областей 3 и о определяется аналогично путем побайто-
вого логического сложения соответствующих областей иа диске 2 с областя-
ми четности на диске 3. Для организации чередования дисков с записью чет-
ности требуется по крайней мерс 3 диска (а точнее, три одинаковых по раз-
меру раздела на трех дисках).
Рис. 5-5. Чередование дисков с записью четности.
ОСНОВЫ ФАЙЛОВОЙ СИСТЕМЫ NTFS
5.2.4 Замена секторов
Избыточное храпение данных используется не только для их восстав* ледд,
после подпой аварии диска, по также п для восстановления .данных одно.
порченного физического сектора. Применяемая (ч1 >isk техники, называем:, .
Aieiioii ceKiHO/KHi (.sector sparing), c<ктоптi> t< >.m, чт< > oh использует свое i ,.
нос хранилище данных для динамической замены потерянных данных,
сектор диска становшся нечитаемым. бточ .метод иеиодьзуг! возможности .
которых жестких дисков, которые предостанляют набор специально ж;;.?:.--
ворованных секторов. Если ltDisk получаса ошибку жесткого диска, он 6ei.»~
.драйвера диска резервный сектор, чтобы заменить им плохой сектор,
шип ошибку FtDisk восстанавливает данные, находившиеся в иоврслскi:,,;
секторе (либо счп гывая их на зеркал ы и >г< * раздела. .11100 вычисляя но ши! -
Нин чередуем»>й области с чепкмтыо), и копирует их к резервный сектор. F Г,
замену секторов вып< спаяет динамически, без вмешательства ФС пли
теля, п этот метод можно использован» с любой Ф<_, поддерживаемой W'ii.tij
NT, па жестких .пиках SCSI.
Если сектор становится плохим, а жесткий диск не прелоеiявляет ; jcj
ныл секторов, или они с него кончились, пли эю нс SCSI диск. То FtDis' _;
может ши с rani лиги, данные. < )п либо заново вычисляет нечнааемыс дани .*
информации че|хдуе.мой области с четное!ью, либо конпрхсТ их мазер**; >
го раздела. Затем эти данные передаются ФС с иретенрежясннсм о том к
зеркалыи>м наб<>ре • >гсалаеь п>.1ык<• одна копия данных или чн> одна и.- Ч< у
с.мых областей недоступна, так что избыточность данных более не нмс-л «о,
для соответствуй чцего сектора. С >т Чч ’ зашкит, (треагнровать на это нрс,",у.г?
денне или сю пп-орпроиати FtDisk будет воестанавяпваи. данные* при ггда*
поньпке системы читать из плохою сектора.
5.3 Восстановление плохих кластеров в NTFS
FtDisk может восстановить данные плохого сектора па отказоустойчив; i
н< •если жесткий диск не является диск- >м SCSI или на нем лаю >| вшлиеь ре:.с; .
сектора,то печена плохого сектора па новый невозможна. Вмеси >.-’>ti сю, ко'дз ’
считывает .чанные изгак* >го секи>ра. i ll >isk i? « станав.т шает шкр 1рмдц и.: л :.
вращает ее вместе с предупреждением, что ocia. ia< ь а« и,ко о. ;на к->iui:-i ,е. i > ’
•Ьайлоные енен’мы 1’ЛГ н IIPFS никак не обрабатывают '«то прсдх-ij '
ине. Ьолес тою, ин эти ФС, ни FtDisk нс ведут гчп плохих сект*: >poi:, :
чтобы E’il Jisk iic пов торял все время 1Ю1 становление данных из ндохоюегк"' (
нользова।ельд<гажензяиухтигьутилитуChkdsk n-iii I’oiinai.(’безал утилни» .' '
ко не н.’ка.яы1Ы для удаления плохого сектора. Chkdsk требует мною rpi 'С
,1.'1я поиска и удаления плохих секторов, a Foinia! уничтожает все данные к
магирус.М! >м разде. ic.
NTFS имеет эквивалент резерг.провання еектор< >в 1 tl >isk в днна.мичеек;:
меняет кластер, еодгрж:ичин н.юхой секи -р, и учи тыкве i ivioxue кластеры, что.
пре.дотвр.|тигь их дальнейшее использование1. Tin функция Cl FS заасйсгку:*г
1 Кик в in \’П?> < сиечшмет переносим<иь путем а.цнеацнп логических K iari-cp
<1 IK* физнчеч КИА 4.1*К1О|Н)В.
Глава 5. Управление томами и отказоустойчивость
если FtDisk не установлен в системе или нс можег заменить плохой сектор.
Когда FtDisk возвращает предупреждение о плохом секторе или когда драйвер
диска возвращает ошибку плохого сектора, XTFS выделяет новый кластер .тля
замены того, который содержит’ плохой сектор. Если FtDisk присутствует
системе, то NTFS копирует восстановленную им информацию в новый кластер-,
чтобы снова добит ься избыточности данных.
Ла рис. 5 6 показана файловая запись MI'S для полыкикисльского <[к|йла,
водном из отрезков котор< >го имеется плохой сектор. Когда XTFS получает ошиб-
ку плохого сектора, она присоединяет содержащий его кластер к своему файле
плохих кластеров. Это предотвращает’ повторное выделение тн до кластера для
другого файла. Затем N'lFx выделяет новый кластер п изменяет отображение
VCN—LCN для файла гак, чтобы оно указывало на ->н>т новый кластер, . ha iijki-
цедура. известная как переназначение hiux<x'<> Kiaemepu (bad-«.luster remap-
ping), иллюстрируется рис. S—7. Кластер номер 1.157, содержащий плохой сек
тор, заменяется па новый кластере номером Н)ф).
Появление плохих секгорок нежелательно, но когда это все— гаки пршс
ходит,то наплучшес решение обеспечивает комбинация NTFS п FtDisk. Если пло-
хой сектор находит ся на томе с избыточностью данных, то FtDisk воссгаиав.-и!-
вает данные и замещает сек nip. если мто возможн< >. Если сектор заме! в пт. нельзя,
FtDisk возвращает предупреждение NTFS. которая заменяет кластер, содержа-
щий плохой сектор.
В том случае, когда FtDisk нс загружен или том нс t конфигурирован как
отказоустойчивый, данные из плохою сектора нсвозаюжпо г.ос< ииюкить. Если
том отформатирован для FAT или IIP1-S и Ftl )isk не м< гжтт косегаповить данные,
то чтение из пл<>хого сектора дает исирс/кказеемыг релульга ты Гслн в плохом
секторе pact Kviai ал иск какие-либо у пранляющяе структуры ФС, ;о целый файл
или группа файлов могут быть потеряны (иногда даже весь диск). В лучшем слу-
чае будут' потеряны некоторые данные файла, содержа >и.,то плохой сектор (ча-
сто все данные, рай к егожепиые г. данном, секторе и за ним !> e'cc того, вн< >лнс
верояпю, что ФС FA) и HIT S повторно иьгтм.г’т плохой сектор для друг, .го фай-
ла тома, в результате чего проблема воз.ппкиет снова.
Данные
Стандартная
информация
Пользовательский
файл
Имя Дескриптор
файла защиты
1688
ПЛОХО'I
Рис. 5-6. Запись МП ллч пользова!е-льскогс файла, содоржаиуего плохой класгср.
1375
Как и другие ФС, NTFS не в ст «стоя нии восстал»«вить данные плохого <•< к>
тора без помощи FtDisk. Однако опа позволяет существенно уменьшить rfvi
который может быть причинен появлением плохого сектора. Если NTFS :Яу
наруживаст плохой сектор во время операции чтения, опа переназначает клас-
тер, в котором он расположен, как показано на рис. 5—7. Если том нс ск<явь.1и
курировал для избыточного хранения информации, ю NTFS возвращает о-щц-у
кт чтения вызывающем программе. Хотя данные, на холившиеся в данном i; >-b
егере, теряются, но остаток файла и ФС сохраняю тся; вызывающая upoi p:t;,iA|.
может отреагировать па потерю данных соответствующим образом, и i ы-«.< >Г|
кластер больше не будет использоваться при распределении пространств ц;|
томе. Если NTFS обнаруживает плохой кластер во время записи, а нс* чтения, т<,
опа переназначает сто до выполнения записи, п, таким образом, избегает поте-
ри данных и генерации ошибки.
Та же* самая процедура восстановления используется, когда в испорти nn-tM_
ся секторе хранятся данные ФС. Если плохой сектор находится на томе с избы-
точностью, то NTFS заменяет кластер динамически, используя данные, носега-
повленпые FtDisk. Если том не избыточный, го данные невозможно восстано-
вить. и NTFS устанавливает бит в файле тома для указания, что том поврежден.
Стандартная
информация
Имя Дескриптор
файла защиты
________Данные________________
стартовый стартовый число
VCN LCN кластеров
О ,.1?57 1
Файл
плохих
кластеров
VCN О
LCN
1357
Стандартная Имя Дескриптор
Рис. 5-7. Переназначение плохого кластера.
При перезагрузке системы утилита Chkdsk NTFS проверяет данный бит, и если
он установлен, то Chkdsk исправляет иовреаденне ФС, реконструируя метадан-
ные NTFS.
Таблица 5-1. Сводка сценариев восстановления данных с использованием FtDisk и NTFS
FtDisk усгановлен... FtDisk не установлен.. С любым типом диска
Со SCSI диском, имеющим резервные сектора С ОТЛИЧНЫМ от SCSI диском или с диском без резервных секторов'
Отказоус- тойчивый том* 1. FtDisk itocciaiiaivin- ваетданные 2. FtDisk выполняет замену сектора ( seen >г sparing) - заменяет плохой сектор резервным 3. ФС не сообщается об ошибке 1. FtDisk hoiттпнавлп- наегданные 2. FtDisk возвращает дан- ные Ф(имеете с предуп- реждением о плохом секторе 5. NTFS выполняет пере назначение к vacmepa (cluster remapping)
Обычный 1 FtDisk tic может’ нос- 1. FtDisk нс может нос- 1. Драписр диска
ТОМ стаиовить данные 2. FtDisk возвращает’ < шщбку плохого сект< >ра файловой системе 5. NTFS выполняет пере- назначение к. иктера Потеря данных ci in к »в| ггь да иные 2 FtDisk возвращает ФС они юку тик >хог< > егкчн >ра Л NTFS выполняет пере- назначение /с lacmepa Потеря данных’ ш >з!<| >;|щаег они 1бку плохчл о сектора 2. NTFS в.ыгюлняет переназначение к ia- стера Потеря ,'1аниых*
FtDisk нс может применить замену сектор* >к пи в < >дпом пч следи* minx случаен- 1) нс SCSI жесткие
диски, нс имени стандартного интерфейса для замены секторов, 2> некоторые жесткие .•теки не
обеспечивают аппаратной поддержки замены секторов, a SCSI диски, v которых она есть, могу» со
временем исчерпа ть весь резерв, если испорчено слишком много сект, (им
t Отказоустойчивым янлястся том одною нз СЛС.ИЮ1ЦНХ танов; зеркальный набор, дуплексный на-
бор к че|хдоиание дисков с |аписыо четности.
* При записи интерн данных не происходит; NTFS переназначает кластер до выполнения записи.
В редких случаях повреждение ФС может произойти даже на отказоустой-
чивом томе. Двойная ошибка может разрушить как данные ФС, так н информа-
цию для их восстановления. Если авария системы происходит и тот момент,
1«лда NTFS записывает, например, зеркальную копию файловой записи MFT, или
индекса имени файла, или журнала транзакций, то зеркальная копия этих данных
ФС об1 к шляется 11C п< сп юстыо. Если пекле псрезафузк! i ст гстс-мы < ян i юка t ни >xoi о
сектора возникает в том же месте первичного диска, где расположены данные,
зеркальная копня которых была записана нс нолнектыо, то NTFS нс может восста-
новить информацию из зеркального образа диска. Для обнаружения таких по
врежденнй системных данных в NTFS реализована специальная схема. Если обна-
ружено нарушение целостности, то в 4>айле тома устанавливается бит пов|Х-жде-
ння, в результате чего при следующей загрузке системы метаданные NTFS будут
ОС ивы ФАИ О ОИ СИСТЕМЫ IX । Гй
восстаи,истины Chkdsk. Так как и отказ, >vcti >йчпвой к, и 1ф, iiypaiuni диска iionpc-,|,.„
денне данных ФС маловероятно, то к Chkdsk прибегают редко. Эта програду.!;)
поставляется в качестве доп, яш пчелы ion меры предосторожности, а не как
ионное средство восстановления информации-.
В табл. 5—1 сведены данные о том, что происходит при появлении пл, •,*< ,П)
сектора надисковом томе, который отформатирован дчя одной из ФС, под-ед.
жпваемых W indows NT, в различных ситуациях, описанных в данной главе.
Обратите внимание, что если FtDisk установлен, том, на котором ноя.т
ся плохой сектор, сконфшурировап как отказоустойчивый, а жесткий ,.щек
поддерживает замену секторов (и запас резервных секторов нс исчерпан;, щ
тип используемой ФС -- FAT, HPFS или NTFS не имеет значения. FtDi.sk заме-
няет плохой сектор, не требуя вмешателктва со стороны пользователя ii.hi Ф<
Рели Fl Disk не установлен или используется с диском, нс поддержит..;!,,-
Шим резервирования секторов, то за замещение (переназначен не) плохого
сектора или — и случае NTFS — кластера, в котором он находится, отвечает Ф(._
Ни FAT, ин HPFS нс обеспечивают переназначение секторов или кластеров.
Преимущества переназначения кластеров NTFS в том, что поврежденные учас-
тки файла можно исправить без вреда для остального его содержимого (или.
соответственно, без вреда для ФС) и что плохой кластер никогда нс будст сно-
ва выделен для того же или для другого файла.
J Пси,ыьзпвагше Chkdsk для NTFS существенно >п>|ичаеп.я от се нспользокання для ЕдТ u I II'I S ! з‘-
рсд выполнением записи на диск две последние >Гч ’ устанавливают опт изменений тома, который
зачем сбрасывается, когда мынфимцня завершена. Если спин сисчемы произошел ио время выпол-
нения операции вывода, то бит осч-асчся установленным. и после нерс.за,резки машины выполняет*
Chkdsk. Ila N ITS Chkdsk и, нолпястся только Тогда, когда обнаружены неверные или нечитаемые /МП'
ныс <|>С, н *!>,. не может воестаны-аггь п\ по информации избыч'очного чччма или из своих избыто1’
H1.IX crpvKiyp данных из обычном томе. (Дуб.чирую’гся сектор начальной затру ,кн. а также ijipar.'.K'U'
ты MFT, необходимые для зш'рузкп снезтмы и исполнения процедуры воссганоюенпи NTT'S ,->га 3*
быт,imho,чч> rapairrnpye'i, ччч> N ITS всегда сможе! .гагру.шч’ы'я п |ич-сга,|,,шг>ъсама Себя.)
ГЛАВА 6
СЖАТИЕ ДАННЫХ
В версиях MS-DOS 6.U и 0.2 была реализована новая возможность ;v'oi файловой
системы FAT: ежа тис дисковых файлов. Утилита сжатия под названием DoubleSpace
в самом деле удваивала объем дисков FAT, устраняя или по крайней мере от-
кладывая на некоторое время необходимость заменять жесткие диски на новые
модели. Файлы па сжатом томе распаковываются динамически, когда пользова-
тель считывает их, и снова записываются на диск в сжатом виде, когда пользова-
тель их изменяет.
После выпуска первой версии Windows NT, в которой сжа тие данных от-
сутствовало, разработчики NTFS стали исследовать возможность сто примене-
ния в зл ой файловой системе* При разработке программного обеспечения сжа-
тия данных существует противоречие между размером упакованных файлов и
скоростью упаковки п распаковки. Утилита DoubleSpace отчасти жертвует скоро-
стью дчя уменьшения размера сжатых файлов. Чтобы сократить размер файла,
она выполняет сжатие байтов данных, упаковывая их до бита. Дчя NTFS Том Мил-
лер и Еэри Кимура решили отдать преимущество скорост и раса ыковки по сравне-
нию с размером файла и не заниматься побитовыми манипуляциями с данными.
Опи также надеялись реализовать быстрый поиск для операций чтения. На
томе DoubleSpace файловая сист ема FAT должна выполни ть не менее трех обра-
щений к диску, чтобы найти сжатый файл. Используя отображение VCN— LCN,
описанное в гл. 3, NTFS в состоянии найти сжатый файл за одну операцию —
столько же нужно для поиска неупакованного файла.
Кроме ставки на повышение производительности, разработчики NTFS хо-
тели добиться некоторой гибкости, разрешив пользователям выбирать файлы,
подлежащие упаковке, вместо того, чтобы требовать обязательного сжатия всего
тома. Возможность выборочной упаковки файлов позволила бы, например, си-
стемным администраторам идентифицировать редко используемые пли боль-
шие файлы и сжимать только их.
Следующий раздел содержит введение в функцию сжатия данных NTFS па
примере простого случая упаковки разреженных файлов. В втором разделе в
обсуждение включается упаковка обычных файлов.
Сжиис данных в описываемом здесь виде было реализовано в Window > NT. начиная » версии ЗА
ОСНОВЫ ФАЙЛОВОЙ СИСТЕМЫ NTFS
6.1 Сжатие разреженного файла
.’(ля обозначения кластеров файла NTFS использует виртуальные номера k.i ч,,
ров (VCN) от О до in. Каждый VCN отображается к соответствующий лошчи
номер KHacivpa (I.t.Nj, который определяет местоположение iciarivpa на . <ча>
11а рис. о-1 показаны ог|х-.зкп (занимаемые участки дискового пространства, i ;iJ_
малыюго, не сжатого файла, а также их VCN и LCN, на которые они отображу-
Рис. 6-1. Отрезки неупакованного файла.
Данный файл хранится в трех отрезках, каждый по -1 кластера длнн> >й, ц
всего, таким образом, занимает 12 кластеров. Па рис. 6-2 показана запись глав-
ной файловой таблицы (МП ) для этого файла. Для экономии места на диске
атрибут данных в записи MFT содержит только по одному отображению для
гутрезка, а нс по одному для каждого кластера. Обратите внимание, тем нс менее,
что каждому VGN отО до 1 I сопоставлен связанный с ним LCN. Первый элемент
начинается с VCN О п покрывает I кластера, второй начинается с LCN ф также
покрывая 1 кластера, п тщ. Такой формат типичен для неупакованного файла.
Стандартная
информация
Имя Дескриптор
файла защиты______________Данные________________
стартовый стартовый число
__________________VCN LCN кластеров
и '355 4
4 1538 4
. 8 2033 4
Рис. 6-2. Запись MFT для неупакованного файла.
Разреженными (sparer) называются файлы, часто большого размера. •••
торых лишь малая часть содержимою представляет собой ненулевые яаю.жк-
Пример разреженного файла — ра3]хженная матрица, хранящаяся на дгск'1'-
Когда пользователь выбирает файл NTFS для упаковки, то один из сп«>с«1'’1
сжатия, применяемых файловой системой, состоит в удалении из пет'одлннчьь
цепочек пулен. Если файл разрежен, то обычно он сжимается до размера, о'"
ставляющсто лишь часть дискового пространства, необходимого для его хрий1'
ння в нормальном виде. При последующих записях в этот<|тайл NTFS выде.'ыс-
пространство только для отрезков, храпящих ненулевые данные
Па рис. б—3 изображены отрезки упакованного разреженного файла. ’
рат ите внимание на Т' >. ч'юлчя некоторых диапазонов VCN файла (16- 31 и о!
127) дисковое пространство не выделено.
Глава 6. Сжатие данных
VSN О 15
| 1 Данные !
L_J______L—J___L.J____1—J__I___ I I
LCN 133 134 135 136 13? 136 139 140 14 : 142 143 144 145146 147 145
32 47
О I —।———————
Данные
_____________I_I_।_1__L_J__1111
193 194 10519619/198199200201202 Ж3204 205206 207 206
48
I 1 1 Данные 1 1 1
96 97 98 99 100101 102103 104 105 106 107 108109 110 111
128 143
Данные
I I I I I I I I I I I I I I
324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339
Рис. 6-3. Отрезки упакованного разреженного файла.
В записи MFI этого файла пропущены блоки VCN мастеров, которые со-
держат пули, н, таким образом, для них нс выделено дисковое пространство. На-
пример, первый элемен т данных па рис. 6—I начинается с VCN О и покрывает
16 кластеров. Второй элемент перескакивает на VCN 52 и задает еще 16 кластеров.
Когда профамма читает данные из сжатого файла, NTFS обращается к за-
писи МП, чтобы определить, определено ли отображение VCN- LCN для того
участка файла, откуда производится чтение. Если программа читает из не разме-
щенной “дыры” в файле, эго означает, что данные этой части файла состоят из
нулей, и тогда NTFS возвращает нули без обращения к диску. Если программа
записывает в “дыру” ненулевые .данные, то NTFS автоматически выделяет диско-
вое пространство и записывает туда эти данные. Такой метод очень г-ирфективен
для разреженных файлов, содержащих много нулевых данных.
Стандартная Имя Дескриптор
информация файла защиты Данные
стартовый стартовый число
I VCN LCN кластеров
о 133 16
32 193 16
48 96 16
128 324 16
Рис. 6-4. Запись МП для упакованного разреженного файла.
ФАЙЛОВОЙ СИСТЕМЫ NTFS
.2 Сжатие обычных данных
Пример сжатия разреженного файла из разд. <>.1 несколько искусственный. (
описывает “сжатие” в случае, когда целые облает «файле заполнены пулями, t|I
на остальные данные файла упаковка нс оказывает никакого влияния. В г ,1)ь
шинствс файлов данные нс являются разреженными, по тем нс менее их мол.;г11.
упаковать при помощи некоторого алгоритма сжатия.
В NTFS пользователи могут задать сжатие для отдельных файлов иди д-ц,
всех файлов в каталоге. Сжимая файл, NTFS разделяет его необработанные да((_
ныс па единицы сжатия (compression units) длиной по Ю кластеров (раг.ц,
8 Кбайт для размера кластера 512 бант). Некоторые последовательности дапицу
в файле могут упаковываться недостаточно сильно или нс сжиматься вообще
поэтому для каждой единицы сжатия NTFS определяет, будет ли при ее упаков-
ке получен выигрыш хотя бы в одни кластер. Если сжатие не позволяет осщь
бодить даже один кластер, то NTFS выделяет отрезок в 16 кластеров и записы-
вает’ данные единицы сжатия на диск без упаковки. Если же данные мож111;
сжать до 15 или менее кластеров, то NTT’S выделяет только то количество, к(ъ
торос необходимо для хранения упакованных данных, после чего записывает
данные на диск На рис. 6—5 показано сжатие файла, состоящего из четырех
отрезков. Незакрашенные области па рисунке показывают дисковое простран-
ство, которое файл будет реально занимать после упаковки. Первый, второй в
четвертый отрезки упаковываются, а третий нет. Даже с одним неупакованным
отрезком сжатие файла позволяет сохранить 26 кластеров диска, или (Г '.
При записи данных в упакованный файл NTFS гарантирует, что каждый
отрезок будет начинаться с номера виртуального кластера, кратного 1с>. Таким
образом, стартовый VCN каждого отрезка кратен 16, и длина отрезка не превыша-
ет К» кластеров. При работе со сжатым файлом NTFS считывает и записывает за
раз минимум одну единицу сжатия. Однако i ipii записи упакованных дай пах N'lTS
пытается помещать единицы сжатия в фтически смежные области, так ч тобы их
можно было считать за одну операцию ввода-вывода. Размер единицы сжатия
16 кластеров был выбран для уменьшения внутренней фрагментации: чем больше
размер единицы сжатия, тем меньше требуется дискового пространства для хра-
нения данных1 2 *. На рис. 6-6 показана запись МЕГ для сжатого файла с рис. о-5.
Одно из различий между этим упакованным файлом и сжатым разрежен-
ным файлом из предыдущего примера состоит в том, что в данном случат- тр11
отрезка имеют длину менее 16 кластеров. Считывание этой информации 113
файловой записи MFT позволяет NTFS определить, упакованы ли данные в эго»
файле. Каждый отрезок короче 16 кластеров содержит сжатые данные, к<хгор*,и
NTFS должна распаковать при первом считывании отрезка в кэш. Отрезок, ..-ин ни'
которого равна точно 16 кластерам, нс содержит упакованных данных и, таким
образом, не требует распаковки.
1 Заметьте. «ли единица сжатия нс «яэялзтглык» должна храниться в физически смежных класи*
рах, \<»тя на рисунках п этой главе.' показаны пислсдовате.аъныс LCN. Отрезки, занимающие I не-
смежные кластеры, дают несколько более сложные записи MFT, чем показано на ри<. 6—о.
2 Размер единицы сжатия, равный 16 кластерам — это компромисс меазд получением умакоюннь^
файлов наименьшего размер и замещением операции чтения доя пршра.чм. осхтцестаяющих й|4’
НЗВО/1Ы1ЫЙ доспи к <райтам. При каждом промахе кэша должен быть распакован эквнкыент 16 Ма-
стеров (вероятнейть промаха кэша при пронзваты-юм доступе выше, чем при iкх'Лс.тователыюм}
VSN 0 _______
упакованные
данные
LCN 19 20 21 22
16
упакованные
данные
23 24 25 26 27 28 29 30
32 47
неупакованные данные
97 98 99 100101102103104105 1061071081091 112
48 63
неупакованные денные
113 114 115 116117118119120121122
Рис. 6-5. Отрезки упакованного файла.
Если отрезок содержит упакованные данные, т< S распаковывает их во
временный буфер и зачем копирует в буфер вызывай программы. Кроме
того, NTFS помещает распакованные данные в кэш, ому последующее чте-
ние из этого отрезка выполняется гак же быстро, кь'бычнос чтение кэша.
Все обновления файла NTFS записывает в кэш, позв средству отложенной
записи сжимать измененные данные и записывать г- диск асинхронно. Та-
ким образом гарантируется, что запись в упакованнгайл вызывает не боль-
шую задержку; чем запись в неупакованный файл.
NTFS размещает упакованный файл па диске в свых областях, насколь-
ко эго возможно. Как указывают LCN, первые два гире пакованного файла на
рис. 6—5 являются физически смежными, равно кака последних. Если два
или более отрезка расположены последовательно, т<> выполняет опережа-
ющее счит ывание с диска, как и с данными в обычныулах. Поскольку’ чт ение
и распаковка данных из “ненрерывного” файла вьп'лются асинхронно до
того, как программа запросит эти данные, пос.тедуюн’ггерацшг чтения выби-
Стандартная Имя Дескриптор
Рис. 6-6. Запись MFT для упакованного файла.
рают информацию непосредственно из кэша, что значительно повышает । }
11.зв< >д| ггелыв ить ч теш i я,
NTFS спроектирована таким образом, что к< >д, упаковывающий фай.: >.
механизм сжатии (compression engine) — представляет собой заменяемый
дуль. Dto позволит NIT'S со временем применить шли,к- технологии унак'.;-
данных, а также сжимать файлы разных типов. Например, файлы мулы и...
требуют иного хтгоритма сжатия, нежели текстовые файлы.
Два критерия успеха программного обеспечения чпаковкп данных
эго размер» н скорость. Чв> касается размера, упаковка г, NTFS достигло,
личных результатов. Ранние версии DoubleSpace уже сжимали текстовые л
лы приблизительно до 10',. от исходного размера, а исполняемые фай..-., ,,
DLL до 6П то',,. Ранние версии NTFS достигают еще лучших значений сжатия,
некоторые сжатые файлы па 1 1"< меньше, чем после сжатия DoubleSpac e.
при разработке NTFS было решено пожертвова ть размером ради новый.
скорости, тем не менее файлы получаются небольшими, зак как опа iici;;ц,_
зует большое “окно сжатия”; а именно, за каждый вызов средству ежзти., щ._
редается 4 Кбаш. Большое окно сжатия позволят достичь более чф<|и ь., ие-
ной упаковки для многих алгоритмов сжатия.
Что касается скорости, разработка средств сжатия данных в NTFS uiit
нс закончена. Использование неоптнмпзпрованной С—версии меха и чзмз
сжатия практически не замедляет файловый ввод - вывод в NTFS. Разработ-
чики ожидают, что после того, как механизм сжатия NTFS будет переписан
более эффективно на языке ассемблера, скорость упаковки и распаковки
мноп>кратно вырастет.
NTFS выполняет упаковку только пользовательских данных, но нс данных
ФС. В последующих версиях ситуация может измениться.
ГЛАВА 7
ГЕНЕРАЦИЯ ИМЕН ФАЙЛОВ
MS-DOS
IV.IK NTFS, так п HPFS допускают до 25S символов в каждом компоненте толево-
го имени. Имина файлов NTFS могут содержать символы UNICODE, а также не-
сколько точек II пробелы внутри. fl>(. FAT ограничивает имена файлов восемью
символами (не UNICODE), за которыми следует точка п трехепмнолыюе рас-
ширение. Из-за этого ограничения клиенты MS-DOS не могут виден» файлы с
длинными именами на диске HPFS. Длинные имена нс отображаются ни тогда,
когда клиент MS-DOS выдаст команд) Dir, ни когда к-шент MS-DOS—Windows
просматривает каталог. Болес того, утилиты MS-ГХ )S, такие как Хсору, также не
могут обращаться к файлам с длинными именами. В связи с .этим организации,
1ДС имснтпи серверы OS 2 и компьютеры с MS -DOS 1: качестве клиентов, редко
пользуются длинными именами файлов в HI’FS.
Поскольку W indows NT поддерживает клиентов как MS -DOS, гак и MS-DOS
—Windows, разработчики решили, что файлы, созданные N1FS, должны быть ви-
димы п доступны этим клиентам, даже если имена файлов “незаконны” с точки
зрения MS—IX )S. На рис. 1 п|К71Ставлсны различные .и/ю-< тринаниа имен фай нм
(file namespace), поддерживаемые Windows NT, н их соотношение друг с другом.
Подсистема POSIX требует самого большой» пространства имен из всех
остальных сред исполнения приложений, которые имеются в Windows N'l, н по
этому пространство имей X'TFsэквивалентно пространству имен POS1X. Подси-
стема POSIX можс1 создавать имена, невидимые для приложений Win32 н MS-
DOS, включая имена, заканчивающиеся точками или пр» юеламп. В общем случае,
созда ть файл, нсп< >льзуя б< шыи< >е ир< >с i рансгво имен И. )SIX, i ic представляет iipi >-
бле.мы, так как это делается только и том случае, если файл предназначен д-а:
использования подсистемой POSIX пли клиентским компьютером POSIX.
Однако взаимосвязь между приложениями для >2 разрядной версии
Windows (Win32) и прил<тжепнямн MS-IX )S Windows г< >раздо более тесная.
Область Win32 па рис. т—I предо являет имена файлов, которые подсистема
Win32 можс'1 создать на томе NTFS, но приложения MS DOS ii 1о разряди- »й
версии W indows их нс могут гащеть. Сюда входят имена более длинные, чем име-
на формата КЗ MS—IX>h; iimci ia, содержащие символы UNICODE; имена, ci -дер-
жании' песке i.'ibKo точек или начинающиеся с точки, а также те, внутри к< >торых
имеются пробсты. При <. отдании файла с таким именем X1TFS автоматически ге-
нерирует .-тля исто альтернативное имя, типичное для MS DOS Windows N Гото-
бралсает эти короткие имена, когда пользователь просматривает каталог в l-iir
OUI 4--«VI/\UtiUl/| II IVIOI 1X1 I ГЬ
Примеры:
"li.il i-,ggl i
"Uli .Ill .ФЛ11А"
"I- i 1 Il-ill..- 11.?. I
* "l i I.:.5 .‘,1
"li i.ii-z* Vi '' ’lib.»' J n •• i
" lii in Г
n:‘ i? jw
LJJ.1 •.‘i1 л ।’и
Рис. 7-1. Пространства имен файлов Windows NT.
Manager с выбранной в меню View опцией All I'ile Details пли когда в команде Dir
используется ключ /х.
MS-DOS имена файлов это полностью функциональные псевдонимы
для файлов NTFS, хранящиеся в том же самом каталоге, что и длинные иггнз.
Запись главной файловой таблицы (MFT) для файла с автоматически сгенериро-
ванным именем MS-DOS показана на рис. ”-2.
Имя Имя
Стандартная файла файла Дескриптор
информация NTFS MS-DOS защиты Данные
Новый атрибут — имя файла
Рис. 7-2. Файловая запись MFT с атрибутом — именем файла MS-DOS.
Имя NTFS и сгенерированное имя MS-DOS хранятся водной и топ же фай-
ловой записи и, таким образом, относятся к одному и тому же файлу. Имя MS"
D( )s можно использовать для открыт ия, чтения, записи пли копирования фяйы-
Если пользователь переименовывает tpaii;i, используя либо длинное, либо кор >'г
кое имя файпа, то новое имя заменяет оба старых1. Если новое имя недонуепог’
для MS-DOS, то N ITS генерирует для файла новое короткое имя.
1 Жесткие связи Р( )SIX рса милованы аналогии! к». При создании такой связи к файлу И )SIX NTi*>
йакляс! ;(«л винительный aipism г имени файла к оюгвекткующей фай/илюй записи Mil’. Есть. <
на Ко, и отличие. Когда пользователь едаляст файл Р< >51X, имеющий несколько имен t жестких евя
зей), то и файловая запись, и файл остаются на месте «Раил к ею запись уда.-ыюггя только тог/ки
юн'ча удаляется iick-'kviiicc имя »|»яиля (жесткая связь) К то же время, если х файла есть и имя KTPv
и стснсрировашьк- имя MS IX 'S, то по/нлюнатсль мож<-т \казать при усаленми лкммх* из них, и ср*1 л
6\71С1 НСМСД/1СИНО уничтожен.
В настоящее время NTFS на юл ьзуег следующий алгоритм д ы генерации
имени MS-DOS из длинного имени файла:
1. Удали ть из длинного имени нее символы, ко торые недопустимы в име-
нах MS-DOS, включая пробелы и символы UNICODE. Удалить точки в
начале и в клише имени.Удалить весточки, находящиеся внутри имени,
кр< >ме н< )след! icft.
1. Обрезать строку, расположенную перед точкой (если точка есть), до
шес ти символов и добавить в се конец “~1”. Обрезать строку за точкой
(сеян точка присутствует) до трех символов.
3. Преобразовать буквы полученного имени в прописные. MS-DOS нс раз
дичает регистр букв, и эгот шаг гарантирует, что NTFS нс создаст новое
имя, отличающееся от уже существующего только регистром.
I. Если сгенерированное имя совпадает с уже существующим. то увели-
чить число в строке
13 таблице 1 показаны длинные имена файлов с рис. 7—1 и версии MS-
DOS, сгенерирован! пае дтя них NTFS. Приведенный алгоритм и примеры из таб-
лицы I должны дать Вам представление о том, как выглядят имена для MS-
DOS, генерируемые NTFS. Разработчики приложений нс должны полагаться на
этот алгоритм. В будущем он может измениться
Табл. 7-1. Имена файлов, сгенерированные NTFS
Длинное имя Win32 Короткое имя. сгенерированное NTFS
Longl-'ile.Naine LONGH-l
1 !пк'Оск1Х;|Пн-.ФДПЛ U.NICOD-1
File.Nai 1 ie.With.Dots FIl.ENA-l.lK > i
File.N:une2AVith.Dots Fl LENA- 2.1 >< >r
iN jine With F.mlx-ckied Spaces NA.MEWJ-1
BeginningDot bfx;inn~i
“ Начиная и нергип 551, алгоритм несколько «имичнегся *n oiniiэнного :дсгь Так, и? согишотся
M.S 1.ц >S имена ля» нескольких файл» «в, в именах которых первые верные г г точки зрении MS-1 и
<S символов совпадав и, то описанный згпоритм при пенистом только ;мя первых 4 файлов. Д-1 a псе?:
остальных файды* апортом меняется. Первые нк-егь епмвешоь состоят из чисел, рассчитываемых ио
определенному iijKittiuiy, а нос ie.-iiiiie * символа всегда одинаковы
1чцс одно (Лянчи»- заключается и испочиюнании расширенных символов II-» умолчанию. сели в д*шн
ном имени ф;шла используют* я расп!н|млшые символы (например, русские буквы.*, то они либо опус-
каются, шбо (если кроме расширенных символов, в имени нет символ* »в ASCII» заменяются м»1«чи
нацией цифр В Windows _ХТ ЗМ • Sen ice Pack ? появилась 1юз.можн«>сть указать г. реестре значе-
ние, при установке которого расширенные » имволы, входящие в длинное имя *Чдут использоваться
и дан создании MS—IB >S имени в соответствии * установленной кодовой •границей I-h»» удобно с
точки «рения клиентов, работающих i. MS—1>< >>. однако не следует заныкать, что если на icineiнекой
.машине xci.ihorichh кодовая егранипз, (пличная от той. которая ис1к«льзуеггя на сервс|*е л » ф<«*-
мирования имен фамл»ж, досп н к файлам будсч невозможен.
ЗАКЛЮЧЕНИЕ
Как говорилось во введении к этой книге, важнейшей целью разработчики
NTFS было создание не только надежной, по н бысгродсйстрл ющей файлово!
системы. Конкретно, ставилась цель достичь такой нрениводигельпостн npi
работе с диском, которая coo i ветствовала бы или превосходила производитель
ность существующих ФС для персональных компьютеров.
Утверждение Гома Миллера о том, чю восстанавливаемость ФС нс <юяза
телыю должна доепп’ааъся за счет производительности, было основным крн
тернем отбора проектных решений. Гесты, проведенные различными спецпа
лизированными журналами1, показали, что ввод-вывод в NTFS выполняется
1,5 — Н раз быстрее, чем в Windows .VI (со SinartDrive и без) и Ох/2 версии 2..
Результаты тестов сильно зависят от конфигурации аппаратуры и от тоге
было ли тестируемое программное обеспечение 16 или 32-разрядным.
В компьютерных журшиах отмечалось, что высочайшая производитель
ность ввода-вывода в Windows NT достигается не только благодаря NTFS; в боль
шей степени тго резульгаа синергизма между NTFS и диспетчером кэша Window
NT. Действуя совместно, NTFS и диспетчер кэша достигают заметно более высс
кои производительности ввода - вывода, чем другие См2 для персональных ком
пьютеров, обеспечивая в то же время беспрецедентный уровень надежности
развитые срсдста храпения данных для настольных систем и серверов.
1 Iivlc 11 PC Magazine. См. пийлногрзфмю
БИБЛИОГРАФИЯ
Луге, Rick, and Robin Raskin. “Windows NT: Sec How It Runs” PC Magazine 12, no
16 (September 28, 1995) ; 21 1 — A],
Duncan, Ray. “Design Goals and Implementation of the New High Performance File
System.” Microsoft Systems Jottnud (September 1O89): 1-1.5.
Duncan, Ray. Advanced MS-DOS Programming, 2d ed. Redmond Wash.: Microsoft
Press, 1988. В главе “Disk Internals” этой книги, ставшей теперь классической,
обсуждается файловая система FAT.
Kartli. Н. F., and A. Silberschatz. Database System Concepts, 2d ed. New York: McGraw
Hill, 1991.
Patterson, A., Garth Gibson, and Randy H. Katz. “A Case for Redundant Miavs of
Inexpensive Disks, or RAID.” Univ, of California at Berkeley, report no. LCB. CSD
S'7/591, December I98~.
Silberschatz, Abraham, and Peter (Jah in. (Ipcrating System Concepts. 4th ed. Reading,
Mass.: Addison-Wesley, 1994.
Udell, Jon. “Is ITicrc a Better Windows 5.1 Ilian W indows .5.1?" Byte 18, no. 12
(November 1995): SAoo.
The Unicode Consortium. The Unicode Standard: World-Wide Character Encoding.
version 1.0, 2 vols. Reading, Mass.: Addison-Wesley, 1991 92. Предварительную
редакцию Unicode версии 1.1 (требующую версии 1.0) “Unicode Technical
Report no. I” можно получит or Unicode Consortium (415—961—4189). Дан-
ный отчет доступен и в Internet it Unicode—incy'unk odc.org. Кроме того, он
имеется на компакт-дисках .Microsoft Developer’s Network.
толковый СЛОВАРЬ
access control entry (АСЕ) - элемент контроля доступа (АСЕ) элемет
списка контроля доступа (ACL), содержащий идентификатор защиты (S1D)
и набор нрав доступа. Процессу с данным идентификатором защиты ука-
занный доступ либо предоставляется, либо запрещается, либо предостав-
ляется с аудитом. Си. также access control list (ACL).
access control list (ACL) - список кон троля доступа (ACL) — часть .кек-
ритора защиты, в которой перечислены права доступа к данному обы-к-п.
Владелец объекта может управлять доступом к нему и изменя ть .K.Z., разре-
шая или запрещая доступ другим пользователям, ( '.писки киптрепя доступа
состоят из элементов контроля доступа (АСЕ). Си. также access control
entry (АСЕ), discretionary access control, security descriptor.
access right - право доступа - предоставленное процессу разрешение ма-
пипелпровать некоторым объектом определенным способом (например,
путем вызова сервиса). Различные типы объектов поддерживают разные
нрава доступа, хранящиеся в списке контроля доступа объекта (ACL). См.
также access control entry (АСЕ), access control list (ACL).
access token - маркер доступа объект уникальный идентнфнкаюр
пользователя, который зарегистрировался в системе. Маркерам доступа снаб-
жаются все процессы пользователя. Он содержит пользовааельскнй иденти-
фикатор защиты (S1D); имена всех групп, в которые входит пользователь;
привилегии пользователя; имя владельца но умолчанию для всех объектов,
создаваемых процессами пользователя, л также сносок контроля доступа
(ACL), назначаемый таким объектам по умолчанию. См. также security ID
АСЕ - с.п. access control entry.
ACL— см. access control list.
address space - адресное пространство см. virtual address space.
alert - оповещение — асинхронное уведомление, посылаемое одним пото-
ком другому. Оповещение вызывает в строго определенных точках преры
ванне выполнения потока, которому было послано, н заставляет этот поток
отработать асинхронный вызов процедуры (AH'). Си. также alenahle
thread, asynchronous procedure call (APC).
alertable thread —оповещаемый ноток поток, объявивший себя плтжым
к отработке асинхронного вызова процедуры ( АРЕ), i loroi; становится опо-
вещаемым, лнГю ожидая на описателе об-ьекга с указанием, что это ожида-
ние является оповещаемым, либо путем проверки наличия ожидающих АРС.
См. также alert, asynchronous procedure call (APC).
alerter service - сервис оповещений сетевой сервис для посылки систем-
ных оповещений пользователю. См. также service.
alerting a thread - оповещение потока сл/. alert.
ОСНОВЫ WINDOWS NT и NTFS
analysis pass — проход анализа первый из трех просмотров журнал;!
закипп. осуществляемых NTFS при восттановлеппн файловой снст:-Ц1.
(ФС). Во время прохода auaiit.sa NTFS выполняет сканщюванпс в иря
направлении, начиная с последней записи контрольной точки, н обшн. :-е
своп таблицы в памяти, используя информацию нз записей модпфик;!;;;:1"
С/л redo pass, undo pass; си. также checkpoint record.
APC — cw. asynchronous procedure call.
APC object - объект APC представление в ядре сисасмы асинхронно' о ;ijji
зова процедуры (АРС). Это управляющий объект, содержащий адрес Др.;',,
указатель па обьект поток, который будет исполнять данный вызов. < „
также asynchronous procedure call, APT’ queue.
APC queue — очередь APC список объектов-асинхронных вызовов процеду-
ры (АРС), предназначенных для обработки данным потоком. 11pm vie :’вцс
объекта АРС в ачереди АРС потока вызывает программное прерывание уровня
АРС, когда тхток вновь начнет нсполнязкя (при наличии других условий, раз-
решающих это прерывание). Си. также asynchronous pioccdure е all, APCi inject.
API - cw. application programming interface.
application programming interface (API) - интерфейс iipnieiaai(i>ix про-
грамм (API) набор процедур, которые вызываются прикладной зро-
тра.ммой для осуществления низкоуровневых операций, выполняемых ОС
ASMP c.w. asymmetric multiprocessing.
associated IRPs ~ ассоциированные IRP набор пакетов запроса nr.'i.ia
вывода (IRP), порожденных для обработки одного запроса ввода вывода.
Каждый п.з ассоциированных IRP вызывает выполнение некоторой чает
запроса ввода—вывода После обработки всех ассоциированных 1RP зшахк
ввода—вывода завершается. См. также I/O request packet.
asymmetric multiprocessing (ASMP) - асимметричная мультипроцес-
сорная обработка (ASMP) — разновидность мультипроцессорной 'Сра-
ботки, при которой код. ОС всегда выполняется на одном и том же процес-
соре, в то время как другие выполняют только пользовательские задания.
также multiprocessing, symmetric multiprocessing (S.MP).
asynchronous ~ асинхронный возникающий в произвольный момент се-
мени, независимо от сх'нощюго течения программы (пример прорыта.'—е
от устройства). С/л synchronous.
asynchronous I/O - асинхронный ввод-вывод .модель ввода вьп о,’,а, !*
которой приложение продолжает выполнение после выдачи запроса !1*‘
ввод вывод, в то время как устройство выполняет пересылку данных. II;41'
ложспне выполняет синхронизацию с окончанием передачи данных нус'1
ожидания на описа теле файла или события. Си. synchronous I/O.
asynchronous procedure call (APC) - асинхронный вызов процедур*4
(АРС') - феикция. выполняющаяся асинхронно в контексте некоторою т1'
тока. Во время выполнения потока яд|х> генерирует программное п|хры!';1'
ине (при наличии других разрешав я цих его условий) п наиравляс'1 поток и*1
обработку АРС. Си. также APt’ object, АРС queue.
atomic transaction ~ атомарная транзакция - транзакция, содержащая на-
бор модификаций содержимой» диска, рассматриваемых как одна опера-
ция. Си. также transaction.
attribute caching ~ кэширование атрибутов — техника, псп<Г1ьзус.мая под
системой Win.52 для повышения производительности при вызове функций
прорисовки из приложения Win32. Динамически подключаемая библиотека
(DLL) на клиентской стороне запоминает, что приложение изменило не-
которые атрибуты отображения, н посылает информацию об этом серве-
ру Win32 только тогда, когда приложение выводит что-либо па экран.
Си. также hatching.
attribute definition table ~ таблица определения атрибутов — файл NTFS,
который определяет чины атрибутов, поддерживаемые на данном томе, а
также сстанавлпваст, можно ли их проиндексировать, восстановить во врс-
мя операции восстановления <1><2 п т.д.
auditing ~ аудит возможнехть обнаружения и регистрации важных собы-
тий. относящихся к защите, в частности, попыток создания, доступа или
удаления обч>сктов. Дчя регистрации процесса, выполнившего данное дей-
ствие, система защиты W indows NT использует идентификаторы защиты
(SID). С it. также security ID.
authentication ~ аутентификация проверка информации, введенной
пользователем при регистрации в системе. Выполняется аутентификацион-
ным пакетом совместно с подсистемой защиты Windows NT. С.м. питча:
authentication package.
authentication package ~ аутентификационный пакет — программный
модуль, подключаемый к системе защиты Windows NT и позволяющий вы-
полнять регистрацию пользователя в системе при помощи различных уст-
ройств ввода. См. также authentication.
automatic working set trimming ~ автоматическое урезание рабочего
набора техника, используемая диспетчером виртуальной памяти
Windows NT для увеличения объема свободной памяти и системе, ,'(испетчср
сокращает размер рабочего набора каждого пронесся, сеян свободной па-
мяти становится недостаточно. См. также working set.
b+ tree ~b+дерево — структура данных, прсдстамяющая собой сбалансирован-
ное дерево, растущее в ширине , а нс в глубину, благодаря чему минимизируется
число обращений к диску, необходимое дчя поиска нужной записи. Nils нс-
пользест />т (Уух'ь’о для .х|чапеиня индексов имен файдов. Си. также index.
backing store — резервное хранилище — нос итель памяти, например. диск
служащий в качестве режрвноп “памяти" для подкачки страниц при пере-
iio;iiiciiiiH физической памяти. См. также paging.
bad-cluster file ~ файл плохих кластеров — файл NTFS, состоящий из пло-
хих кластеров тома, т.с. из кластеров, содержат них плохие сектора.
bad-cluster remapping ~ переназначение плохих кластеров — мс-ханизх
NTFS, при помощи которого файловая система присоединяет кластер, со
держащий плохой сектор, к файлу плохих кластеров, что предел г.рашае"
выделение этого кластера дтя хранения данных лрушго файла. Затем NTR
выделяет новый кластер и изменяет отображение VCN—LCN дчя данной
файла, гак чтобы оно указывало па новый кластер. Если шохой сск.-О|
находится па зеркальном диске или в чередовании .дисков с записью чет.;,
ст. то NTl^S восстанавянваег данные плохого сектора п копирует ix
новый кластер. .-Угот механизм неренатачетт кчасте/мп' работает на
тинах жестких дисков. <й/. также sector sparing.
base file record ~ базовая файловая запись первая файловая ::ал - ;
главной файловой таблице 1.MF1) для файла, имеющего несколько фа
вых записей. Назомы файловаяшнпсь это тапни., котор>й соотщ-тец .,.,,
файловая ссылка данного файла. Си. также file record, file reference.
batching ~ пакетирование метод, используемый uo/к’ттемой ir,y..- д,..
повышения производитель!влети при вызове функций прорисовки :г:; । -;1!_
ложенпя Win32. Динамически подключаемая библиоте ка (DLL) па । u.
кон стороне помещает вызовы функций нптерфкйса прикладных про
(API) для рисования в очередь и посылает их серверу одним сообщс:.:-—м.
когда очередь заполняется либо когда пользователь выполняет вно. q,
также attribute caching.
bitmap file ~ файл битовой карты файл NIT’S, в котором храните.! цп.
формация о распределении пространства на томе Атрибут данных : фай-
ловой записи данного файла содержит битовую карту, каждый бит китикц’,
представляет кластер тома, указывая, свободен кластер пли занят.
boot file ~ загрузочный файл системный файл, в котором храпите., кол
начального загрузчика Windows NT
cache flushing ~ сброс кэша принудительная запись на диск соде;жи-
мо! о кэша.
cache manager ~ диспетчер кэша компонент системы ввода-вывода, .тре-
доставляющпи сервис кэширования файлов для ФС и редиректора Wir.D >vvs
NT. Для перемещения страниц с диска в память п обратно диспетчер »ны
использует механизмы подкачки диспетчера виртуальной памяти.
cache miss ~ промах кэша — попытка потока управления осуществить доспи
к части кэшированного файла, которая отсутствует в кэше. При попытке ijic-
петчера кэша скопировать данные в пользовательский бус|х?р происходи!
страничная ошибка. Тогда диспетчер виртуальной памяти, в свою очередь,
вызывает соответстврощпп драйвер <Ш ’ для обращения к .драйверу ,цт да и
копирования содержимой» файла с диска в кэш. Си. также cache manager.
cache write through ~ сквозная запись - режим работы, при котором из.’— «.-
ння, вызванные каждой операцией записи, немедленно сбрасываются па д к'ь
callback ~ обратный вызов — запрос, посылаемый сервером клпси' ? **
процессе обработки запроса последнего. Обратный вызов нужен с ер* !’'
дая получения дополнительной информации о клиентском запросе.
также loc al procedure call.
carefill write ~ точная запись - жлгорнт.м обновления данных на диске, гр1'
дотвращающнй недопустимые нарушения целостности <1>С’ в случае е*1®1
ФС с точнойзашлт унорядочннас! запросы ил ввод вывод и оргапи-';'1’1
изменения данных па диске таким образом, чтобы любые все же возник':111
нарушения целостности можно было легко и полностью псправгпь в у.':'°'
и<х- время. Ср. lazy write.
CDFS ~ CD-ROM file system — ФС для компакт-дис ков.
checkpoint record - запись контрольной точки запись в журнале трап
закипи, которую NTFS периодичес ки заносит в него, чтобы определить, ка-
кая обработка потребуется для восстановления сома, если сбои произойдет
немедленно после внесения этой записи. Сервис журнала транзакций iLFS)
сохраняет номер логической шюледоватсльностп самой последней по г,ре-
мели записи контратиЛ точки в области рестарт журнала гранз.ткппй,
так что NTFS может быстро найти последнюю заинек контрачьнан точки
в ходе восстановления после- сбоя. См. также log tile, logical sequence numbers
(LSNs), restart area, update record.
child process - дочерний процесс процесс, созданный друньм процес-
сом, который называется родительским. Дочерний процесс наслелусч неко-
торые плп все ресурсы родительского. Ср. parent process.
CISC — си. complex instruction set computer.
client - клиент — процесс, потоки кото[х»го вызывают сервисы, обеспечива-
емые локальным плп удаленным серверным процессом. В Windows NT связь
между клиентом н сервером осуществляется при помощи средств локально-
го (LPC) плп удаленного (RPC) вызова процедуры. <д/. также client—server
model, local procedure call, remote procedure call.
client-server model - модель клиент-сервер — модель структурирования
приложений или ОС. Система подразделяется па процессы (серверы), каж-
дый нз которых предоставляет набор специализированных сервисов дру-
гим процессам (клиентам). Клиентские процессы запрашивают сервис, по-
сылая сообщения серверным процессам, а последние возвращают результа-
ты посредством другого сообщения. Системы, построенные на строгой
лкмУе.ш Kiueum-celxwp, применяются в распределенных сетях, где серверы
и клиенты могут выполняться на разных компьютерах.
cluster - кластер — единица выделения пространства на диске настраиваемого
размера. В файловой системе FA T размер кластера растет пропорционально
размеру диска. В NTFS размер кластера можно хщавать, но имеется также
размер по умолчанию, оггги.мнзпрованный для конкретного размера диска.
cluster factor - кластерный множитель — размер кластера в NTFS. Клас-
терный .множитель — это количество физических секторов (некоторая
степень двойки) в кластере, обычно в байтах. С'п. также cluster
code set - кодовый набор двоичные коды, используемые для прсдставлс
ния символов некоторого языка.
commit a transaction - подтвердить транзакцию — запись в журнале
транзакций с пифюрмацнеп о том, что транзакция была завершена п запи-
сана в кэш. Ст/. также log tile, transaction.
committed memory - переданная память - виртуальная память, для кото-
рой зарезервировано пространство в файле подкачки страниц. Процесс, ко-
торому передается память, расходует при этом свою квоту в файле подкач-
ки. Си. также reserved memory.
complex instruction set computer (CISC) - компьютер co сложным набо-
ром команд (CISC) - процессор, реализующий мощные, часто сложные
машинные команды. Из-за их сложности выполнение каждой команды ж.ц1ь
мает несколько тактов процессора. Ср. reduce d instruction set computer (Rise-
compression engine ~ механизм сжатия код, реализующий алгоритм о.<г,;1н
compression unit - единица сжатия фрагмент дисковых данных фр.-,с,ч
рованиого размера, который сжимается, записывается и считывается v;(l.
целое. В NTFS размер единицы сжатия составляет 16 кластеров.
concurrent application ~ параллельное приложение приложение,
рос может исполняться в двух или более местах одновременно. В \К :.:к,'ПУ,
NT параллельным является приложение, создавшее более одного ноток;, V;i
равнения в одном процессе либо в нескольких, Си. также process, Uire.ni
configuration manager ~ диспетчер конфигурации — набор ирогра>|4.
пых компонентов, упрощающих сохранение и выборку информации ; ко11.
фигурации системы. Сюда входят реестр конфшурацин, графический рс.
дактор реестра, а также средства распознавания оборудования, в том •1ис.ц-
реализованные в ПЗУ. Си. также configuration registry.
configuration registry - реестр конфигурации база данных для хранения
информации о конфшурацин компьютера — например, установленные апщ-
ратныс средства и программное обеспечение, параметры среды и друга.. ии-
с]юрмацня, введенная лицами, использующими систему, (й/. также kev 'vect.
connecting an interrupt object - подключение объекта-прерывания
связывание процедуры обработки прерываний (INK j с некоторым уровнем
прерывания (IRQL). Драйвер устройства обращается к системе для нт'кчн/-
чения объекта—прерывания, что “включает” обработку прерываний для
данного устройства. (л/. также disconnecting an interrupt object, interrupt
object, interrupt service routine (ISR).
console ~ консоль - текстовое окно, управляемое подсистемой Win32. Под-
системы среды направляют на консоль вывод от приложений, работающих
в текстовом режиме.
context - контекст— си. thread context.
context switching ~ переключение контекста сохранение контекста ис-
полняющегося потока, загрузка кон текста другого потока и передача управ-
ления последнему. Переключение контекста выполняется диспетчером я;Ц’;1
Си. также dispatcher, thread context.
control object - управляющий объект обьскт ядра, обеспечивающий .;ejx’“
носимый метод для управления различными системными задачами. В ка-х'Г
управляющих объектов входят объект асинхронный вызов процедуры d"'-
обьект отложенный вызов процедуры (DPC), обьскт процесс ядра и hcCK-jB'
ко обтюктов, используемых системой ввода-вывода, (.и. также kernel оГ’сЧ
copy-on-write - копирование при записи постраничная (в П|ют.< :11'
ложность пообъектной) защита памяти, позволяющая двум процессам >i-'u
стно использован, страниц) до тех пор, пока одни из них не пропзве.<ет ’*'
пись в нес. В этот момент дня щюцссса, выполнившего .запись, согусктся от/ю11'
пая копня измены и кя‘1 c rpannm.i в его вир|уальном адрсхном upoci paiiCiT-e’-
critical section - критическая секция блок кодл, раб<гган.чций с pe-'J'P
сом, который нс ,.ioii)Cicict параллельного доступа к себе. Чтобы t apairritp1’
вать правильность раооты, критическая секция должна одновременно ис-
полняться не device чем одним потоком. Си. также mutual exclusion.
deferred procedure call (DPC) ~ отложенный вызов процедуры (функ-
ция, которая выполняется асинхронно, прерывая нормальное выполнение
потока. /УЛ. выполняет системные задачи, которые были отложены до того
момента, пока уровень прерывании процессора нс опустится ниже диспет-
черского IRQL. Си. также DPC object, DPC queue.
demand paging - подкачка по запросу метод подкачки страниц, при ко
тором загрузка страницы в физическую намять откладывается до момента
страничной ошибки. Си. также fetch policy.
desired access rights ~ запрашиваемые права доступа набор нрав дос-
тупа, запрашиваемых потоком при открытии описателя объекта, Си. так-
же granted access rights.
device object ~ объект-устройство - системный объект, который представ-
ляет физическое, логическое или виртуальное устройство и описывает его
характеристики. Скгмюп—устройство связан с объектом-драйвером. См.
также di iver object.
dirty page table - таблица измененных страниц — структура данных, ко-
торую NTFS поддерживает в памяти для хранения информации о том, какие
страницы кэша содержа! изменения структуры ФС, спи не записанные на
диск. Таб’тца нлиененных страниц используется для восстановления ФС.
См. также transaction table.
disconnecting an interrupt object ~ отключение объекта-прерывания —
отсоединение процедуры обработки прерываний от некоторого уровня
прерываний (IR(V)L). Драйвер устройспя обращается к системе для отклю-
чения объекта -накрывания, в результате чего происходит “выключение”
обработки прерываний для данного устройства. См. также connecting ап
interrupt object, interrupt object, interrupt service routine (ISR).
discretionary access control - избирательный контроль доступа защн
та, которую владелец обтюкта назначает объекту, устанавливая различные
права доступа разным пользователям и группам пользователей. Права, уста-
новленные нзбнрате.1ьны.м контролем доступа, могут быть ограничены
полномочным контролем доступа. Си. также mandatory access control.
disk mirroring - зеркализация диска процедура дублирования раздела
диска на двух или нескольких .тисках, предпочтительно подключенных к
разным дисковым контроллерам, чтобы данные оставались доступными при
сбое диска или контроллера, Су/. также fault tolerance.
disk striping - чередование дисков обьеднненне группы дисковых разде-
лов одного размера, находящихся на разных дисках, в один том с записью
данных тома участками по всем дискам. Такая техника позволяет нарз-ысль-
по выполнять несколько операций ввода—вывода для одного тома. См. так-
же disk striping with parity
disk striping with parity ~ чередование дисков с записью четности
вариант чередования дисков, при котором на них выделяются некоторые
участки для хранения контрольной суммы, так чтобы при сбое диска можно
было восстановить данные при помощи операции “исключающее ИЛИ”. Си.
также disk striping, fault tolerance.
WINDOWS NT и NTFS
dispatcher - диспетчер модуль ядра, ведущий учет шипков, гот>::.|,
исполнению, выбирающим порядок их выполнения и вызывающий
ключснис контекста между потоками, t.w. также context switching.
dispatcher database - база данных диспетчера набор глобальных ец.,.
тур данных, используемым ядром для того, чтобы (лслсжнвать, какие
кп готовы к исполнению и как распределяются исполняющиеся г. . ?>
между процессорами. База данных включает в себя очередь гоп <
диспетчера. См. также dispatcher, dispatcher ready queue.
dispatcher object - диспетчерский объект - обыгт ядра, поддери
щии синхронизацию и реализующий семантику “занят/свободен”, се. ,,/6,
же kernel object, signaled state, nonsignaled state.
dispatcher ready queue - очередь готовности диспетчера - erp. i n,,.
данных в базе данных диспетчера, предназначенная для отс.тежт
потоков, готовых к исполнению. Она представляет собой набор '
дей, по одной для каждого приоритета планирования. См /.как.ч.\-
dispatcher, dispatcher database.
domain controller - контроллер домена — сервер в сетевом домене, :атн:с--
ряющин параметры регпетрапни пользователя. См. также authentiia'ion.
DPC - см. deterred procedure- call.
DPC object - объект DPC объект ядра, негкыьзуемый для аснихронног--.- вы
полпенни системной функции. ?)то управляющий обьект, содержащие xt-
рес отложенного вызови процедуры (DPG), подлежащего иснолп.щщь.
Ядро помещает объекты 1.)РС, ожидающие выполнения, в глобальную оче-
редь DPC. См. также deterred procedure call (UPC), DPC queue.
DPC queue ~ очередь DPC управляемая ядром структура данных, содержа-
щая отложенные вызовы процедуры (DPC), которые ожидают выполнения.
Если в очерет/ DPC присутг-гвует объект DPC, то ядро выдает програм .им-’
прерывание уровня DPC. Процессор, получивший такое прерывание, лгрг-
даст управление ядру, которое исполняет все DPC из очереди. Си. и.../же
deferred procedure call (DPC), DPC object.
driver object - объект- драй вер системный обвею, который предс те.ляс'
индивидуальный драйвер в системе и сообщает диспетчеру ввода вы идя
адреса точек входа драйвера. Объект—драйвер может быть связан с не; ; <•№'
кпми объектамн-усгройгтва.мн (каждый из которых представляет
ство, ynpaiviacMoc данным драйвером). См также decice object.
duplex set - дуплексный набор разновидность зеркального набора, в
poll зеркальные тома пахо.-рггся на дисках, управляемых разными копq >
рамп. Таким <х>ра:к>м, гарантируется избыточность данных даже к случае ,'*‘Я
контро/пера диска (а не только при сб<к- диска). Си. также mirror, mirsт ч‘-
dynamic-link library (DLL) - динамически подключаемая бмблиеыёь’*1
библиотека интерфейса upnioia;nn>ix программ (API), аостсп к к<л>
.для приложений пользовательского режима осуiiicctivihctcm при imuoiU1
обычных вызовов н|юпе.'1ур. Код функции API нс вютчастся в польз ----''
тельский исполняемый файл. Вместо ;тг< н о (>С aim >матнчески м<«дифпн..}*'
ст образ пенолняемоП' i|>aibia во время вьикглнеиня, помещая в псг< > ук;:--:''
телн на процедхры DLL.
environment subsystem ~ подсистема среды защищенная подсистема
(сервер), реалнзеющая в Windows NT среду исполнения н интерфейс при
кладпых программ (API), такие как Win32, MS-DOS, I’OSIX или OS/2, (акая
подсистема перехватывас) вызовы API и реализует их, обращаясь к базовым
сервис ам Windows N'T. ей/, также integral subsystem, protected subsystem.
exception ~ исключение синхронное ошибочное состояние, возникшее в
результате исполнения некоторой машинной команды. Исключения могут
быть либо ошибками, которые сюнаруживлются аппаратной частью (напри-
мер, деление на (>), либо ошибками, обнаруженными программно, такими
кк нарушение сторожевой страницы. Ст/. также exception handlei',
structured exc eption handling, trap handler
exception dispatcher ~ диспетчер исключений модуль ядра, который
запускает обработку исключений, передавая управление «мзработчнка.м. опре-
деленным в программе, или, если таковые отсутствуют, системным обработ-
чикам исключений по умолчанию. Ci/. также exception и exception handler.
exception handler ~ обработчик исключений - код, который вызывается
для обработки исключений. Существует два тина обработчиков исключе-
ний: блочные (включая обработчики завершения) и системные ио умолча-
нию. Си. также exception, structured exception handling, termination handler.
executive ~ исполнительная система c.u. NT executive.
executive object ~ объект исполнительной системы ехтьект NT, види-
мость которого для пользовательского режима обеспечивается некоторым
компонентом исполнительной системы NT. Для манипулирования объекта-
иа иснат и/тельной системы используются сервисы, экспортируемые
исполнительной системой NT.
extent ~ экстент — <л/. run.
FAT -- Си. file allocation table.
FAT file system ~ файловая система FAT — ФС, арадпцпонно используемая
в системах MS-DOS.
fault tolerance ~ отказоустойчивость — способность компьютера и ОС эле-
ratrnio ехбрабатывать катастрофические события, такие как отключение пи-
тания пли сбои аппаратуры. Обычно отказоустойчивость подразумевает
возможность либо продолжать работу без потерн данных, либо корректно
остановить и вновь запустить систему с продолжением всей обработки, вы-
полнявшейся в момент сбоя.
FC.B -- <л/. file control block.
fetch policy - стратегия считывания алгоритм, при помощи которою
система виртуальной памяти определяет, когда средство подкачки должно
ncpcMccrirn. странице с диска в память. \\ iodous NT нспользус! модифици-
рованный алгоритм нодкачкп по запросу. Си. также demand paging.
file allocation table ~ таблица размещения файлов.
file control block (FCB) - блок управления файлом — структура данных
N ITS, которая используется для поиска файла на диске по указателю на
файловый объект. 1'СН щхуктавляст одни открытый файл и содержи ! его
файловую ссылку. Си. также file reference, stream control block.
file handle ~ описатель файла — описатель файлового обьекта. Gw. та
file object.
file namespace ~ пространство имен файлов - множество имен фай.ч,(,
допустимых в OG NTFS поддерживает пространства имен файит
DOS/Windovvs. 52—«битной Windows, OS/2 HPFS и POslX.
file object ~ файловый объект — объект неполнителыюй системы, с,.. <-;а.
щий представлением открытого файла, каталога, тома или устройства. у(/
также executive object.
file record ~ файловая запись — запись в главной файловой таблице (МГт
соответст вующая некоторому дисковому файлу. Файловая запись п,а.ц-
тнфнцируется соответствующей файловой ссылкой. Gw. также fijt
reference, Blaster file table (MFT).
file reference ~ файловая ссылка — (»4—битное значение, состоящее из но-
мера последовательности и номера файла, которое NTFS псполызчет дчя
идентификации файла. Номер последовательности, используемый для внут-
ренних проверок. увеличивается на единицу всякий раз, когда позиция
файловой записи MFT используется повторно. Помер файла соответствует
позиции файловой записи (пли базовой файловой записи) в главной файло-
вой таблице (MFT). См. также base file record, file record, master file tabic (MIT).
file-mapping object ~ объект-проекция файла — версия подсвечены
Win32 для объекта—секции NT, фоновым хранилищем которого яитястся
npoct (ируе.мый файл.
frame-based exception handler - блочный обработчик исключений -
обработчик исключений, связанный с некоторой процедурой или частью
процедуры. Ядро вызывает блочный обработчик при возникновении ис-
ключения внутри соответствующего блока кода. блочный обработчик мо-
жет либо < >бработать iвключение, либо снова возбуд!ггь исключет тс, передав
его в охватывающий блок кода, либо игнорировать исключение и нродол-
жил, исполнение программы с точки его возбуждения. Си. таьже
exception, structured exception handling, termination handler.
granted access rights ~ предоставленные права доступа — набор нрав
доступа, предоставленных системой защиты потоку, который открывай!
описатель объекта. Предоставленные права являются неполным подмноже-
ством запрашиваемых прав доступа. Менеджер объектов сохраняет предок'
давленные права в описателе объекта, возвращаемом потоку. См. также
desired access rights,
HAL — см. hardware abstraction layer.
handle — cm. object handle.
hard link count ~ счетчик жестких связей — сметчик количества кат алоге-*4
файловой системы POSIX, которые ссылаются на данный файл.
hardware abstraction layer (HAL) ~ слой абстрагирования от оборудова-
ния (HAL) — динамически подключаемая библиотека (DLL), нзолируюта’*
исполнительную систему NT от особенностей аппаратных платформ раз-
ных произвол! ггелей с тем, чтобы достичь максимальной переносимости < * -
HAL реализует функции, обеспечивающие абстракции интерфейсов ввода
Толковый словорь
вывода, контроллера прерываний, аппаратных кэшей, механизмов меж-
процессорных коммуникации н гд.
high performance file system (HPFS) - высокопроизводительная файло
вая система (HPFS) - ФС, разработанная для OS/2 версии 1.2 в целях пре-
одоления ограничений, присущих ФС ТАГ, которая используется в MS-DOS.
В иен поддерживаются длинные имена файлов, возможность задания а трибу-
тов для файла, более быстрый поиск файлов и другие усовершенствования.
HPFS — см. high performance file system.
idempotent operation - идемпотентная операция — операция, выполне-
ние которой более одного раза имеет нейтральный эффект. Операции по-
втора и отката NTFS иде.мпотентны.
idle thread - поток простоя — системный поток, который исполняется тогда,
когда ни один другой поток нс готов продолжать выполнение. Поток. про-
стоя исполняет отложенные вызовы процедур (DPC) и инициирует переключе-
ние контекста, когда другой поток становится готовым к выполнению. В много-
ироцессорной системе имеется по одному потоку простоя на процессор.
IDT — c.w. interrupt dispatch table.
IFS — см. installable file system.
impersonation ~ имперсонация способность потока одного процесса
становиться (с точки зрения системы защиты) идентичным потоку другого
процесса и выполнять операции от имени последнего. Используется подси-
стемами среды и сетевыми сервисами при доступе к удаленным ресурсам по
запросу клиентского приложения.
index ~ индекс — набор имен файлов, составленным как выборка по како-
му-либо атрибуту файла и хранящимся в отсортированном виде для уско-
рения доступа.
indexed buffer ~ индексным буфер — отрезок, равный 2 Кбайт или размеру
кластера (в зависимости от того, что больше), содержащий часть индекса.
Индексные буферы реализуют структуру данных Ь+ дерево, используемую
для сортировки записей индекса. Си. также Ь+ дерево.
installable file system ~ подключаемая файловая система (IFS) — ФС.
которая может быть загружена в ОС. динамически. Windows N’i поддержива-
ет несколько подключаемых ФС одновременно, включая ФС ГАГ, NIFS
HPFS* и CDFS. ОС автоматически определяет формат носителя данных и
использует для доступа к нему соответствующую Ф(.
instruction execution unit - блок обработки команд — машинно-зависи-
мый блок кода в виртуальной DOS—машине (VDM), действующий как обра-
ботчик ловушки на процессорах Intel и как эмулятор команд Intel па про
рессорах MIPS. См. также virtual DOS machine.
integral subsystem ~ интегрированная подсистема - защищенная иодси
стема (сервер), выполняющая задачу, существенно необходимую для фуик
ццонироваиия ОС. В группу таких подсист ем входят сетевые серверы н под
система защиты. Си. также environment subsystem и protected subsystem.
* В Whitlows VI’ версии -1.0 Ф(_; HPEs ис подчерки пгагген.
interrupt ~ прерывание - асинхронно возникающее- состояние < >С. ком
прерывает нормальное нын< ишение н передает управление обработчику ц.?
[шванпя. I !]>ерывания обычно генернрупися устройствами ввода
когда последним необходимо обслулгннание со стороны i1роцсссора.
также exception, trap handler.
interrupt dispatch table (IDT) - таблица распределения прерывавH(
(IDT) структура данных, своя для каждого процессора, нсшыыг.-;.,
ядром, чтобы отыскать обработчик при возникновении прорыва и и а. ;
также interrupt dispatcher.
interrupt dispatcher ~ диспетчер прерываний подкомпонен т m;,-' ....
чика ловушки ядра системы. Служит для определения источника пре:.ьщ..
ння и передачи управления процедуре, предназначенной дчя его <>•>;.
кп. См. также interrupt.
interrupt object - обтатсг-прсрыпапие — объект ядра, позволяющий драй,
веру устройства связать (‘"подключить’’) процедуру обработки npcpunuiiui
(LSR) с уровнем прерывания (IRQL). Э го управляющий объект, содержа ищу
адрес ISR, IRQL. на котором устройство выдаст прерывания, и вход и табли-
це распределения прерываний (IDT) ядра, с которым должна быть ст-ьзаш
ISR. См. также connecting an interrupt object, interrupt dispatch table
interrupt request level (IRQL), interrupt service routine (ISR).
interrupt request level (IRQL) - уровень прерывания (IRQL) степень
приоритетности прерывания. Каждый процессор имеет текущий
прерывания, который может понижаться и повышаться потоками гнраск-
ния. Прерывания на уровне, равном текущему уровню прерывания пгм _:.се-
сора или ниже, блокируются (маскируются), в то время как прерви я,
уровень которых выше текущего у/ювня прерывания процессора, не мас-
кируются. См. также masking interrupts.
interrupt service routine (ISR) ~ процедура обработки прерывания -
процедура в составе драйвера, которая вызывается обработчиком гцадтша-
ння ядра, когда устройство возбуткдаст прерывание. Данная процедура гат-
павлпвает генерацию новых прерываний устройством и сохраняет шк.юр-
мацию о его состоянии, после чего помещает в очередь отложенный вызов
процедуры (DPC) драйвера для завершения обработки прерывания. См. так-
же deferred procedure call (DPC).
invalid page - недействительная страница - виртуальная страница, о- ра-
щение к которой вызывает страничную ошибку. Такая страница дсласл'Ч
снова действительной либо путем ее за1рузки с диска, либо нулем восста-
новления и?, списка резервных или .модифицированных страниц. В
тпвном случае обращение к такой странице вызывает нарушение заг.и
памяти. См. также valid page.
I/O completion - завершение ввода-вывода последний шаг обраб< скп
запроса ввода вывода системой ввода—вывода. Типичные действия, выа •
няемые на этом шаге, это удаление- внутренних структур данных, си-лап1'
ных с запросом, возвращение информации вызывающей программе, зап;:-'1’
финального состояния операции в блок состояния ввода вывода, уегаи111’'
лснис файлового обтс-кта и (iuiii) события в состояние готовност и, а такал"-
возможно, размещение в очереди асинхронного вызова процедур (ЛРС). <*>•
также asynchronous proccdute- call (APC).
I/O manager ~ диспетчер ввода-вывода компонент исполнительной си-
стемы Windows NT, объединяющий различные части системы ввода-выво
да. < 1н определяет правила и методы для приема .запросов на ввод -вывод и
передачи их ФС и драйверам устройств. Кроме того, диспетчер ввада- вы-
вода содержит код, общий для нескольких драйверов.
I/O request packet (1RP) ~ пакет запроса ввода-вывода (IRP) структу-
ра данных ;ыя представления запроса ввода - вывода и управления сю обра-
боткой. Диспетчер ввода вывода создает /А'/’ и передаст сто последовательно
одному или нескольким драйверам. Когда драйверы завершают операцию,
диспетчер завершает ввод- вывод и удаляет Hd' Oz. также I/O completion.
IOSB си. 1 О status block.
I/O status block (IOSB) - блок состояния втюда-вывода (IOSB) струк-
тура данных, передаваемая в качестве параметра сервису ввода-вывода. По
завершении обработки диспетчер ввода-вывода записывает в итог блок
окончательное состояние опершиin.
IRP — ciz. I/<) request packet.
IRP stack location ~ область стека IRP — область данных и пакете запроса
ввода- вывода, содержащая информацию, необходимую конкретному драй-
веру для выполнения его части запроса. Каждый драйвер, участвующий в
обработке запроса, имеет отдельную область стека в IRP. См. также I/O
reqiiest packet (IRP).
IRQL - c.u. interrupt request level.
ISR - cm. interrupt service routine.
kernel ~ ядро — см. NT kernel
kernel mode ~ режим ядра - привилегированный режим работы процессо-
ра, в котором исполняется системный код Windows NT. Поток, исполняю-
щийся в режиме нд/ш, имеет доступ к системной памяти и к аппаратур:. с./л
user mode'.
kernel object ~ объект ядра — существующий во в|Х*мя исполнения лкземн-
ляр абстрактного зпиа данных, определенного ядром. Ядро задаст поведе-
ние таких объектов и реализует процедуры, которые вызываются исполни-
тельной системой NT для работы с ними. Объекты ядра делятся па две кате-
гории: управляющие объекты и диспетчерские объекты. ()бъекты обеих кате-
горий используются в качестве основы для объектов исполнительной системы
Windows NT. Си. также control object, dispatcher object, executive object.
kernel process object ~ объект-процесс ядра — представление процесса в
ядре. Это управляющий объект, содержащий информацию, необходимую
для загрузки адресного нрхтраиства прщесса, л также для отслеживания
ресурсов процесса и его атрибутов по умолчанию. См. также control object.
kernel thread object ~ объект-поток ядра — представление потока управле-
ния в ядре. Это диспетчерский обьскт. содержащий основную информацию
для направления потока на выполнение. Gv. zzzzZZuMC dispatcher object.
key object ~ объект-параметр - обьскт исполнительной системы, предс тав-
ляющий информацию о конфигурации Системы, которая хранится в рсесг-
|Х‘ См. также configuration registry, executive object.
вы
INDOWS NI и NIF
lazy evaluation algorithms - алгоритмы отложенного вычисления
щая ка тегория алгоритмов, избегающих выполнения лоропгетоящих о?;е|..
цнй до тех пор, пока это не станет абсолютно необходимым. Если не* ,г>,' '
днмость в выполнении операции ие возникает никогда, то время проц-,.,"
ра вообще не расходуется. Диспетчер виртуальной памяти W indows N,’ ’
пользует алгоритмы отложенною вычисления для повышения щхяг,— .
тельности работы с памятью. Примерами служат подкачка страниц
просу, режим защи ты страниц “копирование при записи”, а также рл-,„---
ное резервирование и передача памяти. Си. также committed mer.,<,n
copv-on—write, demand paging, reserved memory.
lazy write - отложенная запись — алгоритм обновления данных на дщ Kv
максимально возможной производнтсльиостыо. Ф(' с omvMVinioii
помещают изменения данных на диске в кэш п выводят оптнмизироваып,
информацию из кэша на диск, часто в фоновом режиме. В системах с • ц(|.
женнай записью степень безопасности данных обычно меньше для ,1ИЬ..
тения производительности. Ср. careful write.
lazy writer ~ средство отложенной записи — группа потоков управлении
диспетчера кэша, которые вызывают диспетчер впрауальной памяти для запи-
си содержимою кэша на диск в фоновом режиме. Си. также cache manager.
LCN — см. logical cluster number.
LI S — cm. log file service.
local procedure call (LPC) facility ~ средство локального вызова проце-
дуры (LPC) - средство оптимизированной передачи сообщений, обеспе-
чивающее коммуникации между двумя процессами, которые вынолняются
на одном и том же компьютере. Защищенные подсистемы исшыь-.хлотс.я
IPC для общения друг с другом и с клиентскими процессами. LPC эш
разновидность удаленного вызова процедуры (RPC), оптимизированная ,ця
локального использования. Ср. remote procedure call (RPC).
local replacement policy' - стратегия локального замещения — алгоритм
замещения страниц, при котором каждому процессу выделяется фиксиро-
ванное количество страничных фреймов. Когда процесс исчерпывает выде-
ленную ему квоту, диспетчер виртуальной памяти начинает переписывай* «1а
диск страницы из рабочего набора процесса, чтобы освободить простран-
ство для обработки новых страничных ошибок, сгенерированных процес-
сом. Си. также replacement policy, working set.
locale -“регион — национальная и (или) культурная среда, в которой ра1Х>'
тает система или программа. Регион определяет язык сообщений и мен*’-
порядок сортировки строк, раскладку клавиатуры, а также форматы ж1'11'5
и времени.
log file - журнал транзакций — файл. который считывается и заннсыгдс'н’1
сервисом журнала транзакций fLFSl Журнал транзакций содержит :еишен
подоперациях транзакции, которые помещает луда NTFS и по которым п1'1
NTFS .можно восстановить после сбоя системы. См. также log file service (I I
log file service (LFS) - сервис журнала транзакций — компонент Windo"’*
NT, ynpaivniioiuiifi протоколированием модификаций данных па диск4'-
NTFS вызывает сервис журнала транзакций для записи информации *'
журнал транзакций, который используется для восстановления тома NTFS
после сбоя системы. <*»/ также log file.
logging - протоколирование транзакций — метод обработки транзакций,
в котором подоперации атомарных транзакций записываются в журнал
транзакций перед тем. как они будут записаны на диск. В случае сбоя систе-
мы полностью запротоколированные транзакции можно повторил,, а час-
тично запротоколированные отменить после повторного запуска сис-
темы. См. также log file, transaction.
logging area ~ область протоколирования — гмхтастъ журнала транзакции,
в которую сервис журнала транзакций (LFS) помещает записи NTFS, исполь-
зуемые для восстановления тома к случае сбоя системы. LFS симулирует бес-
конечную область протоколирования путем циклического ее повторного
использования. См. иииме log tile, log tile sen ice (LFS), restart area.
logical cluster numbers (LCNs) ~ логические номера кластеров (LCN) —
числа, получаемые в результате нумерации кластеров от начала тома (D) до
его конца (г;). NTFS осуществляет поиск кластера, умножая его /ZjV на кла-
стерный множитель тома, что дает физическое смещение кластера в байт ах
Ср. virtual cluster numbers (VCNs); си. также cluster, cluster factor.
logical sequence numbers (LSNs) ~ номера логической последователь-
ности (LSN) числа, получаемые в результате нумерации записей в жур-
нале транзакций. Сервис журнала транзакций (LFS) увеличивает значения /.VV
по мерс помещения в журнал новых записей. Количество возможных /.S.X'
фактически нс ограничено. Gw. также log file.
logon process - процесс регистрации в системе — процесс Windows NT,
потоки которого обрабатывают попытки пользователей зарегистрировать-
ся в системе. Прежде чем предоставить пользователю доступ к системе,
процесс проверяет введенную регистрационную информацию при помощи
подсистемы защиты.
LPC - см. local procedure call.
LSN -- см. logical sequence numbers.
mandatory access control ~ полномочный контроль доступа — зашита
объекта, назначенная ему администраторы системы. Такой контроль обыч-
но помечает объект некоторым уровнем защиты, например “секретно” и
“совершенно секретно”. Для доступа к объекту пользователи должны иметь
права ссхитзстствующего уровня. Полномочный контрть доступа имеет
преимущество ио сравнению с избирательным контролем доступа, назна-
чаемым объекту ст о владельцем. См. также discretionary access control
map ~ проецировать, преобразовать — транслировать виртуальный адрес
в физический.
mapped file - проецируемый файл — файл, загруженный в находящийся в
памяти объект—секцию. Отображая проекции секции на свете адресное про-
странство, процесс может работать с файлом как с большим массивом
виртуальной памяти. Диспетчер виртуальной памяти автоматически вы-
полняет- подкачку страниц файла, загружая их с диска но мере необходимо-
сти и записывая обра тно измененные страницы. Си. также map, paging tile.
mapped file I/O - проекционный файловый ввод-вывод — ввод |«.ы
выполняемый путем чтения записи виртуальной памяти, резервным
лшцем которой является файл. Gw. также map|xd file.
marshal ~ преобразование преобразовл! те пара.мецхтв процедуры в < <- г . ,t.
ленный формат для передачи по сети. См. также remote procedure rail
masking interrupts ~ маскирование прерываний повышение v,. .i|(„
прерываний (IRQL) щхгцсссора для блокирования прерываний па нс *
всех более низких уровнях
master file table (MFI) ~ главная файловая таблица (MIT) — база дк:.-.,Мх
в которой хранится информация о содержимом тома NTFS. МГ'[ и|н,„-."аг.
ляет собой таблицу, ряды которой соответствуют файлам то.ма, а ко.тог.;ц
атрибутам файлов.
master/slave system ~ система ведущий-ведомый — см. asymmetric ттц;-.
processing (AS.MI').
messenger service ~ сервис передачи сообщений — сетевой сервис для
приема и отображения сообщений от других систем. См. также sen ice.
metadata ~ метаданные — данные и файлы, используемые NTFS дан реализа-
ции структуры ФС.
method ~ метод - связанная с типом объекта функция, которую менеджер
объектов вызывает автоматически в строго определенные моменты жпащ
обтюкта. См. также object type.
MFT — Utz. master file table.
Microsoft interface definition language (MIDI.) — язык определения интер-
фейса фирмы Microsoft.
MIDI, compiler ~ компилятор MIDI. — компилятор, обрабатывающие ис-
ходные файлы на языке MIDI, и генерирующий процедуры—заглушки для
приложений, использующих RPC. См также, remote procedure call ‘!<Г"л,
stub procedure.
mirror ~ зеркало — дисковый том, используемый как копия тома (р.тгчюгч
или меньшего размера) на другом диске .тля обеспечения избыточноеш
данных. Отказоустойчивый драйвер Windows NT записывает изменения
данных на диске как в основной, так и в зеркальный раздел.
mirror set - зеркальный набор два раздела па разных дисках, o.tiu из
которых NTFS использует в качестве зеркала другого. См. также niirr-н.
modified page writer — средство записи измененных страниц но-.’ок
диспетчера виртуальной памяти, выполняющий асинхронную зашк ! :i:1
диск виртуальных страниц, содержимое которых было изменено, что yt" ~.Н'
чпвает, таким образом, число доступных страничных фреймов.
mount ~ смонтировать — под готов! го. том к использованию. В NTFS пр’1'
цссс лнтти/ютптя включает поиск и открытие файлов ФС, копирован:11’
части их содержимого в операт ивную намя ть н исполнение процедуры i
становления ФС.
МРК ~ МРК — С1/. multiple provider router.
multiple provider router (MPR) - маршрутизатор миогоеетекого досту
iu днпьмнчсекс. подключаемая бнб.ш ссека (i>L!.i, к; .тория определяет
Kai.vio сеть (и, c.'k-:i<р.атечыпi, ФС, г;;е,чуст ни<с-.!ь:<-•:агз, когда -ipii i-ec.T;..
вызыгснт <|>vt па и 111 интерфейса при1-жа.т1 ->i.\ upoipai »i (Ai’t» Wtn/C
для i:|mk-г.rrpa удаленных !I‘C.
multiple I'NC provider (Vtl’P) - Mitoroairmtii i’N'C ,'ц.и,'..-,ер, „m.^e/i,,
loliillfl, какую пт:, -и, c,T .tic •4»TX’. Ii.i I';, ФО CMC. lyci IlCHojB.-c лить, . .да. ;-r„:
ложенне шаст Функчен -пасла i-ыгоча ;:лтс|х1>ейс:> :;риК1адн г-; ш-.»
грамм (ЛР1> 'Xiii.V’ ,;.чя открытия удаленных файт-ж.
multiprocessing ~ мультипроцессорная обрабсика и.-; ..,х’.'л’. t.oe рс
полис;.ИС 1>С/..Ы'Х или ё-o.ire : п-оков ;а ра :ых процессора:;. Г« uis-.c- •
My'ibTiiiipoiivecopiii'U обработкой может ладейстса.-ьат’ д<>-юг интел -т
процессоры п .••Ц1'>гс>ц|1<>1!(,д'еорном коиныотсре. Как правило, му.чьтнвро
нсееыре.ач <'С яши-ется i: многозадачной. ?ы/. мм«г nmhnaskiiig.
multiprogramming - мультипрограммирование см. tnukitas* i-in.
multitasking - многозадачность непс мнение процессов-m не скольких no
токов путем переключения контекста с одного из ttiix на другой, ii реют»
тале мосенс'чн.лется mt.noami одн<-временного г.--н1<;.ц!епп>1 г-сех ног-., иг о:
пмкме preemptive niiihiiasking.
multithreading ~ многопоточность снос- -оно-ть приложения ныпо.’тм гь
ся одновременно п д1ал нян более местал нуге-.; использования неско.чькн.'
гюгоког.. Данный Tep.Miiii иногда нс 1;<>.-1_эз\-,тся ;ц. син« зим .мнчгийц^г-пкч
гпп примени Н-.1ЫЮ к ОС, ii-X'Viep' .Hiiai'tnieH н.-тнкн унравле-ни!!.
MVP c.'.i. multiple uniform naming c<.п-.’е.тх m provider.
mutual exclusion взаимное иск.-но-сенис мредогврапц пне одновре-
менного нено.чьл--iiaima peevpea более чем одним погоюм. Н'кш.’чиче П:
К'ппчение неой.х'.'дпмо, сеян системный рес урс' не доте кает iiiipa.-'!.:ie?ii>iion
доступ;, к себе и.-тн сеян иара.члея'.в-« лсио. ян те мо.кст прп|.схти к ос
н;Х'деказуемыч резулыаг.1М. <2к. ’е cr'.tieal section.
name retention - удержание имен процедура, iiocpc.ктг.ом которой дне
петчер объектов сохраняет имя объекта в нр«н ПХ!!1<тве имен. Когда .чакры
вае'ся п<я?ле,'1ннй oiiiiea’ieai. данного объекта. tiiciic'iHep обьекп>г- у'кгчяс
илы об1>ект;; пз пространства имен, что дсксст нев-ычотным откр.ытп
обьекта в дальнешпем. бм. пшкчее object u-tention.
named pipe - именованный канал — механизм коммуникации между нр<;
цеч самп, позволяющий npoHveev нос ылать данные другому лока льному п. п
удалс! пк >му npoi ссссу
namespace ~ пространство имен cu. file namespace.
national language support (NI«S) - поддержка национальных языке»
(NLS) пп'1срфсйс прикладных программ (API), позволяют! in npi сюжет ilia:
по.-1\чап. информацию, спсцпфпчтю д ia даннся-о репюна. <л/. пиислсе locah
native services ~ базовые сервисы сне темные сервисы, дослуп к которы:
из пользоватслыкоп» режима обеспечивается пснолннте.-н-ной системе1
ХГ при помощи нодспетем среды, динамически подключаемых бпблноте
(DLI.) и других системных программ.
NDIS — см. network driver interface specification.
NetBEUI transport ~ транспортный протокол NetBEUI — расширенный
пользовательский интерфейс NetBIOS (Network Basic Input/Output System
Extended User Interface). Основной транспортный протокол, используемы,-,
Windows NT для локальных сетей*. Си. также NetBIOS interface.
NetBIOS interface - интерфейс NetBIOS — интерфейс программирования
позволяющий обмениваться запросами ввода—вывода с удаленным komih,Kj2
тером. Изолирует прикладные программы от сетевой аппаратуры.
network domain ~ сетевой домен — набор рабочих станций и серверов
которые используют одну базу данных диспетчера защиты учетных записей
(SAM) и могут администрироваться как группа. Пользователь, имеющий
учетную запись в данном сетевом домене, может регистрироваться в доме-
не с любого из входящих в него компьютеров. См. также SAM database.
network driver interface specification (NDIS) ~ спецификация интер-
фейса сетевого драйвера (NDIS) — интерфейс Windows NT для драйве-
ров сетевых плат. Обеспечивает независимость производителей сетевых
плат от сетевого транспорта, так как все драйверы транспортов обращают-
ся к сетевым платам только через этот интерфейс. Сетевые драйверы, напи-
санные для интерфейса NDIS (NDIS драйверы), переносимы в среду вирту-
альных драйверов устройства MS-DOS.
network redirector ~ сетевой редиректор — сетевое программное обеспе-
чение, которое принимает запросы ввода—вывода для удаленных файлов,
именованных каналов или почтовых ящиков и пересылает их сетевому сер-
веру на удаленном компьютере. В Windows NT редиректоры реализованы как
драйверы ФС См. также network server.
network server ~ сетевой сервер — сетевое программное обеспечение, об-
рабатывающее запросы на ввод-вывод или вычисления от клиентского
компьют ера. Сетевые серверы Windows NT могут быть реализованы как сер-
верные процессы или как драйверы. См. также protected subsystem.
NLS — см. national language support.
nonpaged pool ~ резидентный пул — часть системной памят и, страницы из
которой никогда не откачиваются на диск. Ср. paged pool.
nonprivileged processor mode ~ непривилегированный режим процес-
сора — см. user mode.
nonresident attribute ~ нерезидентный атрибут — атрибут файла, значе-
ние которого хранится в одном или нескольких отрезках (экстентах) вне
записи главной файловой таблицы (MFT) и отдельно от главной файловой
таблицы. Ср. resident attribute; см. также run.
nonsignaled state ~ состояние «занят» — атрибут, имеющийся у каждого объек-
та, тип которого поддерживает синхронизацию. Поток, ожидающий объек-
та, который находится в состоянии “занят” продолжает ожидать до тех пор.
* Протокол NetBEUI широко применялся только в первых версиях Windows NT. Несмотря па то, что
этот протокол обеспечивает наивысшую скорость работы, рад присущих ему недостатков (таких,
как невозможность маршрутизации и сильная зашумленность в большой сети) позволяет эффектив-
но его использовать только в небольших локальных сетях.
1илкивыи иливорь
пока ядро не переведет объект в состояние “свободен”. См. также signaled
state, synchronization.
NT (new technology) — новая технология.
NT executive ~ исполнительная система NT — часть ОС Windows NT, ис-
полняющаяся в режиме ядра. Она реализует структуру процессов, коммуни-
кации между процессами, управление памятью и объектами, планирование
потоков управления, обработку прерываний, ввод-вывод, поддержку сети н
контроль доступа к объектам. Интерфейсы прикладных программ (API) и
другие средства реализуются защищенными подсистемами пользовательс-
кого режима. См. также protected subsystem.
NT file system (NTFS) ~ файловая система NT (NTFS) — ФС с восстанавли-
ваемостью, разработанная для ОС Windows NT. NTFS использует парадигмы
базы данных, обработки транзакций и объектов, чтобы обеспечить защиту
данных, надежность ФС и усовершенствованные возможности, отсутствую-
щие в других основных современных ФС. Она также поддерживает объект-
но— ориентированные приложения, представляя все файлы как объекты с
атрибутами, определяемыми пользователями и системой. См. также
recoverable file system.
NT kernel ~ ядро NT — компонент исполнительной системы NT, управляю-
щий процессором. Выполняет планирование и переключение потоков, об-
работку прерываний и исключений и мультипроцессорную синхрониза-
цию, а также реализует примитивные объекты, используемые исполнитель-
ной системой NT для создания объектов пользовательского режима.
NTFS — см. NT file system.
object ~ объект — один экземпляр некоторого определяемого NT типа объек-
тов, существующий во время выполнения. Содержит данные, работа с кото-
рыми возможна только посредством сервисов, определенных для объектов
данного типа. См. также object type.
object attribute - атрибут объекта — поле данных в объекте, определяющее
или хранящее состояние последнего. Доступ к атрибуту объект! осуще-
ствляется путем вызова объектного сервиса.
object class ~ класс объектов — см. object type.
object directory object ~ объект-каталог объектов — объект, хранящий
имена других объектов, примерно также, как каталог’ ФС хранит имена фай-
лов. Обеспечивает средства i юддержки иерархической структуры имен для
объектов Windows NT.
object domain - домен объектов — авт ономный набор объектов, доступный
через иерархию имен диспетчера объектов NT, но управляемый другим дис-
петчером объектов (например, системой ввода—вывода NT).
object handle ~ описатель объекта — индекс в таблице объектов npoi iecca.
Используется для ссылки на открытый объект и содержит набор прав дос-
тупа, предоставленных процессу-владельцу описателя. Содержит также ин-
формацию, указывающую, наследуется ли данный описатель дочерними
процессами. Программы применяют- описатели для ссылок на объекты при
вызове сервисов объектов. См. также object table.
object manager ~ диспетчер объектов — компонент исполнительной спец-.,
мы NT, который создает, удаляет и отвечает за именование ресурсов < )<
хранящихся в виде объектов.
object model - объектная модель — модель структурирования программ в<ч<_
руг обрабатываемых ими данных. Формат структур данных скрывается внут ри
объектов, и для манипуляции данными объектов программы должны использо.
ватъ специально определенные сервисы. Основная цель объектной .модели
максимально увеличить повторное использование кода. Си. также object.
object retention - удержание объектов — процедура, посредством которой
диспетчер объектов сохраняет их в памяти. Когда удаляется последняя
ссылка на объект, диспетчер удаляет временный объект из памяти. с;м
также name retention.
object service - объектный сервис — системный сервис для манипулирова-
ния объектом, видимый пользоват ельскому- режиму. В Windows NT объект-
ный сервис, как правило, считывает или изменяет атрибуты объекта и ис-
пользуется главным образом защищенными подсистемами.
object table - таблица объектов — специфичная для процесса структура
данных, содержащая описатели всех объектов, которые были открыты сто
потоками. См. также object handle.
object type ~ тип объектов — абстрактный тип данных, набор сервисов, ра-
ботающих с экземплярами этого типа, а также набор атрибутов объекта. Тип
объектов определяется посредством типового объекта. См. также object
attribute, type object.
Open Systems Interconnection (OSI) reference model ~ опорная модель
OSI — модель программного обеспечения, определенная ISO (международ-
ной организацией по стандартам), которая стандартизует’ уровни обслужи-
вания и типы взаимодействия для сетевых компонентов. Опорная модель
OSI определяет семь уровней коммуникаций между компьютерами и уста-
навливает, за что каждый из них отвечает.
OSI — си. Open Systems Interconnection.
page - страница — блоки виртуальной памяти с последовательными вирту-
альными адресами, которые диспетчер виртуальной памяти копирует из
физической памяти на диск и обратно в процессе подкачки. См. также page
frame, paging.
page fault - страничная ошибка — ловушка процессора, возникающая пр11
обращении потока по виртуальному адресу, который находится па недей-
ствительной странице. См. также invalid page, paging.
page frame - страничный фрейм — диапазон последовательных физичес-
ких адресов, используемый для хранения содержимого виртуальной стра-
ницы. Размер страничного фрейма (а зачастую и размер страницы) жестки
определяются процессором. В большинстве систем размер страничного
фрейма и размер страницы одинаковы. См. также page, paging.
page frame database ~ база данных страничных фреймов — структура дан-
ных, используемая диспетчером виртуальной памяти для записи состояния
всех физических страничных фреймов. См. также page frame.
Толковый словарь
page table ~ таблица страниц — таблица, особая дчя каиуцжо процесса, кото-
рую диспетчер виртуальной памяти использует для отобршкенпя виртуальных
адресов в физические адреса или в адреса на диске. Таблица страниц состоит
из элементов таблицы страниц (РТЕ). См. также page table entry (ИГЕ), paging
page table entry (РТЕ) ~ элемент таблицы страниц (РТЕ) - .запись в таб-
лице страниц процесса. Содержит информацию, необходимую системе
виртуальной памяти для поиска страницы при обращении потока по недей-
ствительному адресу. Размер н формат РТЕ зависят от процессора. Си. так-
же invalid page, page table.
paged pool ~ нерезидентный пул — часть системной памяти, страницы из
которой могут быть откачаны на диск. Ср. nonpaged pool.
pager ~ средство подкачки — компонент диспетчера виртуальной памяти,
выполняющий операции подкачки страниц. См. также paging.
paging - подкачка страниц — операция, выполняемая программным обеспе-
чением управления виртуальной памятью и состоящая в пересылке ст раниц
из памяти на диск при переполнении физической памяти. При обращении
потока к странице, отсутст вующей в данный момент в памяти, происходит
страничная ошибка, средства управления памятью находят по таблице стра-
ниц требуемую страницу на диске и загружают ее в память. См. также
invalid page, page fault, page table.
paging file ~ файл подкачки — системный файл, в котором находит ся содер-
жимое виртуальных страниц, от качанных из памяти. См. также backing
store, mapped file.
parent process ~ родительский процесс — процесс, создавший другой про-
цесс, называемый дочерним. Дочерний процесс наследует все или некото-
рые из ресурсов родительского процесса. Ср. child process.
placement policy - стратегия размещения — алгоритм, используемый сис-
темой виртуальной памяти для определения места в физической памяти, куда
следует поместить данные, подкачиваемые с диска. Диспетчер виртуальной
намята использует набор списков FIFO (первым пришел, первым обслужен)
страниц для учета свободных страниц и выбора свободной страницы при
загрузке информации с диска в процессе обработки страничной ошибки.
port ~ порт — коммуникационный канал, по которому клиентский процесс вза-
имодействует с защищенной подсистемой. Порты реализованы как объек-
ты Windows NT. См. также local procedure call.
power notify object ~ объект-уведомление питания — объект ядра, позво-
ляющий драйверам устройств зарегистрировать процедуру восстановления
питания. Это управляющий объект, содержащий указатель на процедуру
драйвера устройства, которую ядро вызывает при восстановлении напряже-
ния после сбоя питания.
power status object ~ объект-состояние питания — объект ядра, позволя-
ющий драйверам устройств определить, произошел ли сбой питания. Эго
управляющий объект, содержащий логическую переменную, которую драй
вер устройства может проверить перед началом операции, если прерыва-
ние ее недопустимо. Если сбой питания уже произошел, то драйвер не на-
чинает операцию.
РРТЕ — см. prototype page table entry.
preempt - вытеснить — прервать испол! tenne потока, когда поток с более выС{)
ким приоритетом буде т готов к выполнению, и переключить контекст на щ», (
См. preemptive multitasking.
preemptive multitasking ~ вытесняющая многозадачность — разиовир
ность многозадачности, при которой ОС периодически прерывает нспг,;ь
пение потока и выполняет другие, ожидающие потоки. Вытеснение предо,.
вращает монопольный захват процессора одним потоком и позволяет щ4
подняться другим потокам. См. также time quantum.
primary domain ~ первичный домен — сетевой домен, с которым связана
данная учетная запись пользователя. См. также network domain.
privileged processor mode ~ привилегированный режим процессора -
см. kernel mode.
process - процесс — логическая едини! ia работы в ОС В Windows NT процесс
включает в себя виртуальное адресное пространство, исполняемую про-
грамму, один или несколько потоков управления, некоторый объем квот на
пользовательские ресурсы, а также системные ресурсы, которые ОС выделя-
ет потокам процесса ОС. Процесс реализован как объект. См. также thread.
process context ~ контекст процесса — см. thread context.
process tree ~ дерево процессов — иерархия родительских и дочерних про-
цессов, поддерживаемая подсистемами POSIX и OS/2.
processor affinity - процессорное сродство — набор процессоров, на ко-
торых может выполняться данный поток.
protected subsystem ~ защищенная подсистема — серверный процесс,
выполняющий функции ОС- Каждая загцищенпая подсистема Windows NT
работает в пользовательском режиме и имеет' собственное адресное про-
странство. См. также environment subsystem, integral subsystem.
protocol - протокол — набор правил и соглашений, в соответствии с которы-
ми производится обмен сообщениями по сети меящу двумя компьютерами.
Сетевое программное обеспечение обычно реализует несколько уровней
протоколов, расположенных друг под другом.
protocol stack ~ стек протоколов — набор и последоват ельность сетевых
протоколов, используемых для передачи сетевого запроса от одной маши-
ны к другой. См. также protocol.
prototype page table entry (РРТЕ) - прототипный элемент таблицы
страниц — структура данных, аналогичная обычному элементу таблицы
страниц (РТЕ), но указывающая на страничный фрейм, используемый со-
вместно несколькими процессами. См. page table entry (РТЕ), section object.
provider ~ компонент сетевого доступа — родовое имя программ! юго обес-
печения, позволяющего Windows NT функционировать в качестве клиент3
удаленного сетевого сервера.
provider interface ~ интерфейс сетевого доступа — программный интер-
фейс, позволяющий производителям сетевых средств сделать их удаленные
ФС доступными для просмотра приложениями, которые используют
Толковый словарь
Windows—интерфейс прикладных программ (API) WNet. См. также multiple
provider router.
PTE — cm. page table entry.
quick LPC ~ быстрый LPC — форма локального вызова процедуры (LPC),
используемая некоторыми частями подсистемы Win32 и ее клиентами.
Быстрым IPC повышает скорость передачи сообщения благодаря тому, что
он не использует объекты-порты, хранит сообщения в разделяемой памяти
и использует встроенный механизм синхронизации.
quota ~ квота — ограничение на использование ресурсов, связанное с учетной
записью пользователя. Диспетчер объектов выдает процессу некоторую
порцию пользовательской квоты всякий раз, когда один из потоков этого
процесса создает или открывает описатель объекта. Если квота израсхо-
дована, то пользовательский процесс более не сможет создавать объекты
или открывать их описатели до тех пор, пока не освободит некоторые из
занятых ранее ресурсов.
raise an exception ~ вызвать исключение — намеренно передать управле-
ние обработчику исключения, после того как оно произошло. Программное
обеспечение возбуждает исключение, когда происходят ошибки или возни-
кают неожиданные состояния. См. также exception, exception handler.
recoverable file system ~ восстанавливаемая файловая система — ФС.
гарантирующая. что в случае отказа питания или другого катастрофическо-
го сбоя системы ни одна ФС не будет разрушена и ни одна из модификаций
диска не останется в незавершенном состоянии. При перезагрузке системы
восстанавливается целостность структуры дискового тома.
redirector - редиректор — сетевое программное обеспечение, которое при-
нимает запросы ввода-вывода для удаленных файлов, именованных кана-
лов или почтовых ящиков и пересылает их сегевому' серверу на другую
машину. В Windows NT редиректоры реализованы как драйверы ФС. См.
также network server.
redo information - информация для повтора — информация в записи мо-
дификации, сообщающая NTFS о том, как повторно произвести обновление
данных тома (выполнить подоперацию транзакции) во время восстановле-
ния ФС. Ср. undo information; см. также log file, update record.
redo pass - проход повтора — второй из трех просмотров журнала транзак-
ций, осуществляемых NTFS при восстановлении ФС. Во время прохода по-
втора NIT’S выполняет сканирование в прямом направлении, начиная с са-
мого старого номера логической последовательности (LSN), обнаруженного
на этапе анализа, и повторяет модификации (гиги подоперации) т ранзакций,
которые были полностью запротоколированы перед сбоем системы, но чьи
изменения, возможно, не были применены к тому. Ср. analysis pass, undo pass.
reduced instruction set computer (RISC) ~ компьютер с сокращенным на-
бором команд (RISC) — процессор, реализующий небольшой набор про-
стых команд, которые используются совместно для выполнения более слож-
ных операций. Благодаря простоте команд и большому количеству регист-
ров, почти все команды занимают только один цикл процессора, н после-
дний может работать на более высокой тактовой частоте, нежели большим-
сто процессоров со сложным набором команд (CISC). Ср. complex instruc-
tion set computet (CISC).
remote procedure call (RPC) - удаленный вызов процедуры (RPC)
средство передачи сообщений, позволяющее распределенному приложе-
нию вызывать сервисы, расположенные на разных компьютерах в сети. цс.
зависимо от их фактического местоположен! ы. Операции пересылки ц,
сети выполняются автоматически. RPC обеспечивает процедурно -ориентц.
рованный подход к работе с сетью в противоположность тратiciгортгк
ориентированному. Ср. local procedure call.
replacement policy - стратегия замещения — алгоритм, используемый еи.
стеной виртуальной памяти для определения виртуальной страницы, кото-
рую следует удалить из памяти, чтобы освободить место для данных, подка-
чиваемых: с диска. Windows NT использует стратегию локального замещения
по принцип) удаления самых старых (по времени использования) страниц
reserved memory - зарезервированная память — набор адресов вирту-
альной памяти, выделенных по запросу некоторого потока. Си. также
committed memory.
resident attribute ~ резидентный атрибут — атрибут файла, значение кото-
рого целиком содержится в файловой записи MFT. Ср. nonresident attribute;
си. также file record, master file table (MF I ).
restart area - область рестарта — область, расположенная в начале журнала
транзакций, куда сервис журнала транзакций (I-FS) записывает контекстную
информацию для себя и для NTFS. Информация из области рестарта по-
зволяет NTFS начать в< кстановление тома после сбоя системы. Си. также
log file, log file service (LFS), logging area.
robustness - устойчивость — способность программы работать нормально
или продолжать работать нормально в неожиданных ситуациях.
roll back - откатить — отменить транзакцию, протоколирование которой в
журнале транзакций было прервано из-за системного сбоя. Си. также
transaction, transaction processing.
RPC — cu. remote procedure call.
RPC transport provider interface - интерфейс доступа RPC к транспор-
тным протоколам — DLL, являющаяся интерфейсом между средствами
удаленного вызова процедуры (RPC) и программным обеспечением сетевого
транспорта. Позволяет RPC работали с различными транспортами.
run - отрезок — также называется экстентом (extent). Непрерывная област ь ня
диске, используемая для хранения части или всего нерезидент ного атрибута
файла. Си. также nonresident attribute.
SAM database - база данных SAM — база данных для контроля доступа, вклк’"
чающая имена пользователей и пароли. Администрирование этой базы <>0'
ществляегся при помощи программы User Manager. Си. также securii)
accounts manager (SAM).
SCB — см. stream control block.
script - набор символов — система символов, используемая для записи тек-
ста на одном пли нескольких языках.
section object ~ объект-секция — объект, представляющий область памяти,
которую могут совместно использовать два или более процесса. Процесс
также может создать безымянный объект-секцию, представляющий соб-
ственную память процесса. См. также view.
sector sparing ~ замена секторов — функция отказоустойчивого драйвера
диска Windows NT, благодаря которой нечитабельный сектор динамически
замещается, а его содержимое восстанавливается. Содержимое либо копи-
руется с зеркального диска, либо восстанавливается по данным чередую-
щихся дисков с записью четности. Замена секторов работает только для
поддерживающих ее SCSI-дисков. См. также bad-cluster remapping.
secure logon facility ~ средство защищенной регистрации в системе —
программное обеспечение в составе защищенной ОС, управляющее некото-
рым классом устройств для регистрации в системе и гарантирующее, что
все пользователи введут' корректную идентификационную информацию,
прежде чем им будет позволен доступ к системе.
security accounts manager (SAM) ~ диспетчер защиты учетных записей —
защищенная подсистема Windows NT, поддерживающая базу данных SAM и
обеспечивающая интерфейс прикладных программ (API) для доступа к этой
базе. См. также SAM database.
security descriptor ~ дескриптор защиты — структура данных, присоеди-
няемая к объекту для защиты его от несанкционированного доступа. Содер-
жит список контроля доступа (AGL) и управляет аудитом действий над
объектом. См. также access control list, auditing.
security ID ~ идентификатор защиты — имя, уникальное во времени и в
пространстве, идентифицирующее пользователя для подсистемы контроля.
Идентификаторы защиты (SID — security ID) могут идентифицировать
как отдельного пользователя, так и группу пользователей.
security reference monitor ~ справочный монитор защиты — компонент
исполнительной системы Window s NT, который сравнивает маркер доступа
процесса со списком контроля доступа (ACL) к объекту и определяет, по-
зволить ли потокам npoi jecca открыть описатель объекта.
security subsystem - подсистема защиты — неотъемлемая подсистема, кото-
рая сохраняет правила безопасности для данного компьютера и участвует в
процессе регист рации пользователей в системе. См. также integral subsystem.
server ~ сервер — процесс, один или несколько потоков которого принима-
ют на обработку запросы от клиентских npoi teccoB. Сервер реализует набор
сервисов (видов обслуживания), которые он предоставляет клиентам, ис-
полняющимся либо на том же самом компьютере, либо на разных компью-
терах в распределенной сети. Си. также client, local procedure call, network
server, remote procedure call (RPC).
server message block (SMB) protocol - протокол SMB — сетевой протокол,
использованный первоначально в сетях Microsoft, а позднее и в другом се-
тевом программном обеспечении для персональных компьютеров. Он оп-
ределяет особый формат для пакетов данных, пересылаемых ио сети. Реди-
ректор и встроенный сервер Window's NT используют SMB для взаимодей-
ствия друг с другом и с компьютерами в сетях LAN Manager. Си. также
network server, protocol, redirector.
server service - сервис сервера — сетевой сервис, поддерживающий интер.
фейс прикладных программ (API) пользовательского режима для управле-
ния сетевым сервером Windows NT. См. также sendee.
service ~ сервис — серверный процесс, выполняющий особую системную
функцию и часто предоставляющий интерфейс прикладных программ
(API), функции которого могут вызываться другими процессами. Серену
Windows NT поддерживаю! RPC, т. е. функции их API могут вызываться <
удаленных машин.
service controller - контроллер сервисов — сетевой компонент, выполня-
ющий загрузку и запуск сервисов Windows NT. Контроллер сервисов также
загружает и выгружает мног ие драйверы Windows NT, в том числе драйверы
устройств и сетевых транспортов. См. также service.
SID — см. security ID.
signaled state - состояние «свободен» — атрибут, имеющийся у каждого
объекта, л ип которого поддерживает синхронизацию. Когда облюкг перево-
дится ядром в состояние “свободен'’, потоки, ожидающие данного объекта,
выходят из состояния ожидания (в соответствии с некоторым набором пра-
вил) и становятся готовыми к выполнению. См. также dispatcher object,
nonsignaled state, synchronization.
single-byte coding scheme - однобайтовая схема кодирования — схема
кодировки символов (кодовый набор), например, Windows ANSI, использу-
ющая для представления каждого символа восемь бит. См. также Unicode.
SMB — см. server message block.
SMP — см. symmetric multiprocessing.
sparse files - разреженные файлы — файлы, часто большого размера, у
которых лишь малая часть содержимого — ненулевые данные.
spin lock ~ спин-блокировка — механизм синхронизации, используемый
ядром и отдельными частями исполнительной системы, который гаранти-
рует взаимоисключающий доступ к глобальным системным структурам дан-
ных в многопроцессорной среде. Поток, ожидающий получения спин-бло-
кировки, эффективно приостанавливает процессор до тех пор, пока блоки-
ровка не будет получена. См. также mutual exclusion.
stream ~ поток — последовательность байтов.
stream control block (SCB) - блок управления потоком — структура дан-
ных NTFS, используемая для поиска файла на диске по указателю г га файло-
вый объект. SCB представляет один атрибут (поток) открытого файла и со-
держит ссылку на блок управления (FCB) этим файлом. См. также Ггк
control block (FCB).
STREAMS — среда разработки драйверов, предоставляемая Windows NT для
создания и переноса драйверов сетевого транспорта.
stripe ~ чередуемая область — 64-Кбайтная область в разделах равного раз-
мера, расположенных на каждом из трех или более дисков. Драйвер отказо-
устойчивого диска Windows NT записывает логически последовательные
данные чередуемыми областями по всем дискам. Такая техника позволяет
1ОЛКОВЫИ
ов ь
равномерно распределить данные между дисками, что повышает производи-
тельность ввода-вывода. Gw. также stripe set, stripe set with parity.
stripe set - чередование дисков — ряд разделов одинакового размера — по
одному на диск, — доступ к которым ФС осуществляет как к одному ло-
гическому тому. /U'im реализации чередования дисков FtDisk (отказоустой-
чивый драйвер диска Windows NT) распределяет логически последователь-
ные данные 64-Кбайтовыми областями по всем дискам. Gw. также stripe,
stripe set with parity.
stripe set with parity - чередование дисков с записью четности — отка-
зоустойчивый вариант чередования дисков, при котором эквивалент одно-
го диска используется для хранения четности каждой области из набора.
Если данные на одном из дисков становятся недоступными, то драйвер от-
казоустойчивого диска Windows NT, FtDisk, реконструирует его содержимое
при помощи информации четности. Gw. также stripe set.
structured exception handling ~ структурная обработка исключений —
способ перехвата и обработки неожиданных ситуаций, последовательно
применяемый по всей ОС. Когда происходит некоторое особое событие,
ОС (или аппаратура) генерирует исключение, и ядро автоматически переда-
ет управление соответствующему обработчику исключения. Gw. также
exception, exception handier.
stub procedure ~ процедура-заглушка — процедура в динамически под-
ключаемой библиотеке (DLL), служащая точкой входа интерфейса приклад-
ных программ (API). Когда данная функция API вызывается клиентским при-
ложением, процедура-заглушка выполняет преобразование переданных ей
параметров в сообщение и посылает его либо локальному серверу (подси-
стеме), либо удаленному серверу на сети. Gw. также local procedure call
(LPC), marshal, remote procedure call (RPC).
symbolic link object - обьект-символическая связь — объект исполнитель-
ной системы, выполняющий трансляцию одного имени объекта в другое.
symmetric multiprocessing (SMP) - симметричная мультипроцессор-
ная обработка (SMP) — мультипроцессорная ( К’, в которой код ОС может1
исполняться на любом свободном процессоре в многопроцессорном
компьютере. Симметричные мультипроцессорные системы обычно обеспе-
чивают лучшую производительность по сравнению с асимметричными. Ср.
asymmetric multiprocessing; см. также multiprocessing.
synchronization - синхронизация — способность потока приостанавли-
вать свою работу и ждать выполнения некоторой операции другим пото-
ком. В Windows NT поток ожидает , пока другой поток не переведет некото-
рый синхронизационный объект в состояние “свободен”. Си. также
signaled state, synchronization objects.
synchronization objects - синхронизационные объекты — группа види-
мых пользовательскому режиму1 объектов исполнительной системы NT.
типы которых поддерживают синхронизацию. Сюда входят потоки управ-
ления, процессы, события, пары событий, семафоры, таймеры, синхрониза-
торы и файлы. Поток имеет возможность ожидать, пока синхронизацион-
ный объект не будет- установлен в состояние “свободен" другим потоком.
Внутри каждого синхронизационного объекта содержится диспетчерский
объект ядра См. также dispatcher object, signaled state, synchronization.
ТСТЬЫ WINDOWS 1X11 И IM I гл
synchronous - синхронный — происходящий и определенное время н являю-
щийся прямым результатом исполнения определенной машинной команды
Ср. asynchronous.
synchronous I/O - синхронный ввод-вывод — модель ввода—вывода, в i«,_
торой приложение выдает запрос ввода-вывода, а система ввода-вывода
не возвращает управление приложению до тех пор, пока обработка запроса
не будет завершена. Ср. asynchronous I/O.
TDI — см. transport driver interface.
termination handler - обработчик завершения — обработчик исключений,
позволяющий приложению гарантировать, что заданный фрагмент кода
всегда будет выполнен, даже если исполнение кода завершилось неожидан-
ным образом. Обработчики завершения обычно содержат код для ость
бождения выделенных ресурсов, чтобы возвратить их системе в случае не-
нормального выхода из процедуры. См. также exception handler.
thread - поток — исполняемая сущность, принадлежащая одному (и только
одному) процессу. Поток состоит из указателя текущей команды, пользова-
тельского стека, стека ядра и набора значений регистров. Все потоки прог tecca
имеют одинаковый доступ к его адресному пространству, описателям объек-
тов и другим ресурсам. Потоки реализованы как объекты. См. также process
thread context - контекст потока — переменные данные, связанные с hci ки-
пением потока. Включает в себя содержимое системных регистров и вирту-
альное адресное пространство процесса, к которому относится поток. Си.
также context switching.
thread dispatching - переключение потоков — см. context switching.
thread object - объект-поток — реализация потока в Windows NT. См.
также thread.
thread of execution - поток управления — см. thread.
thread scheduling - планирование потоков — процесс просмотра очереди
потоков, готовых исполняться, и выбора одного из них для выполнения.
Эта задача возложена на модуль диспетчера ядра NT. См. также dispatcher.
tightly coupled system - сильно связанная система — многопроцессор-
ный компьютер, память в котором совместно используется всеми процессо-
рами. Синхронизация доступа к структурам данных в глобальной памяти
возлагается на ОС.
time quantum - квант времени — временной интервал предопределенного
размера, в течение которого ОС позволяет потоку выполняться, прежде чем
вытеснить его. См. также preempt.
TLB — см. translation lookaside buffer.
token object - объект-маркер — см. access token.
topology - топология — физическая конфигурация машин веет.
TPC/IP transport - транспортный протокол TCP/IP — основной сетевой
транспортный п|хлокол Windows NT для глобальных сетей. Позволяет
Windows NT обмениваться информацией с системами в сетях ТСРЯР
(Transmission Control Protocol/Internet Protocol), а также взаимодействовать
с различными сервисами на UNIX-машинах.
transaction - транзакция - В NTFS - атомарная операция, в которой состав-
ляющие ее подопера! (ии рассматриваются как одна операция Все подопера-
ции (или отдельные обновления) должны быть завершены успешно В про-
тивном случае дгшжен быть выполнен откат тех подопераций которые вы-
полнялись в момент возникновения ошибки. Си. также atomic transaction,
commit a transaction, roll back.
transaction processing - обработка транзакций - метод обновления базы
данных, при котором сбои системы не нарушают корректности или целос-
1 пости базы. Каждая транзакция протоколируется и затем выполняется ато-
марно. Если сбой системы прерывает протоколирование подопераций
транзакции, то на основе информации из журнала транзакций выполняется
откат той части транзакции, которая была завершена к моменту сбоя, и та-
ким образом база данных возвращается к предшествующему корректному
состоянию. См. т акже log file, roll back, transaction.
transaction table - таблица транзакций — структура данных, которую NTFS
поддерживает в памяти для отслеживания начатых, но еще не подтвержден-
ных транзакций. Таблица транзакций используется для восстановления
ФС. См. также commit a transaction, dirty page table.
translation lookaside buffer (TLB) - справочный буфер трансляции
(TLB) — массив в памяти, содержащий отображение виртуальных адресов
в физические для страниц, которые самыми последними по времени ис-
пользовались в системе. TIB имеется как у процессоров MIPS, так и у про-
цессоров Intel, по их структура и использование машинно-зависимы.
transport driver interface (TDI) - интерфейс драйвера транспортного
протокола (TDI) — интерфейс Windows NT, при помощи которого сетевые
редиректоры и серверы посылают драйверам транспортов запросы, связан-
ные с обращением к сети. Интерфейс обеспечивает независимость от исполь-
зуемого транспорта путем сокрытия особенностей конкретных транспортов.
trap - ловушка — механизм процессора для перехвата исполняющегося по-
тока, если происходит необычное событие (исключение или прерывание),
и передачи управления по заданному адресу. См. также trap handler.
trap frame - кадр ловушки — ст руктура данных, создаваемая входящим в
состав ядра обработчиком ловушки при возникновении прерывания или
исключения. В кадре сохраняется состояние процессора, что позволяет
ядру возобновить исполнение прерванного потока после необходимой об-
работки. См. также trap handler.
trap handler - обработчик ловушки — участок кода, вызываемый аппаратно
при возникновении исключения или прерывания. Данный код определяег
тип возникшей ситуации и передает управление соответствующей про-
цедуре обработки. См. также trap.
trusted domain relationship - отношения доверия доменов — довери-
тельные (доверенные) отношения между двумя сетевыми доменами. См.
также network domain, trust relationship.
л on
trust relationship -доверительные (доверенные) отношения — термин,
имеющий отношение к защите от несанкционированного доступа и означа-
ющий, что рабочая станция или сетевой сервер доверяют контроллеру до
мена выполнять для них аутентификацию пользователей при регистрации
последних в сист еме. Аналогично, контроллер домена может доверят ь про-
верку параметров регистрации пользователя контроллеру другого доме-
на. Си. также domain controller.
type object - типовой объект — внутренний системный объект, определяю-
щий общие атрибуты для класса объектов. Каждый экземпляр объекта содер-
жит указатель на соси-ветствующий типовой объект. Си. также object tpx-
UNC — си. uniform naming convention.
undo information - информация для отката — информация в записи моди-
фикации, сообщающая NTFS о том, каким образом выполнить откат т ранзак-
ции, подоперации которой не были полностью запротоколированы перед
сбоем системы. Ср. redo information; с«. также log file, roll back, update record.
undo pass - проход отката — последний из трех просмотров журнала
транзакций, осуществляемых NTFS при восстановлении ФС. Во время про-
хода отката NTFS выполняет сканирование в обратном направлении, от-
катывая обновления, или подоперации всех транзакций, которые не были
полностью запротоколированы или подтверждены до момента отказа си-
стемы. Ср. analysis pass, redo pass.
Unicode — стандарт кодировки символов, имеющий фиксированную длину
представления одного символа (16 бит) и позволяющий закодироват ь все
алфавиты в мире. Си. также script.
uniform naming convention (UNC) names - имена по правилам едино-
образного именования (UNC) — имена файлов или других ресурсов, ко-
торые начинаются с последовательности \\, означающей, что ресурс распо-
ложен па удаленном компьютере.
uninterruptable power supply (UPS) ~ источник бесперебойного пита-
ния (UPS) — подсоединенный к компьютеру модуль с резервными аккуму-
ляторами, позволяющий в случае отключения пит ания сохранить содержи-
мое памяти на время, достаточное для нормального останова системы.
update record - запись модификации — запись, которую NTFS помещает в
журнал транзакций для регистрации изменения содержимого тома (подо-
перации транзакции) перед тем, как выполнить это изменение. Запись
модификации содержит информацию повтора и от мены для данного изме-
нения тома См. также checkpoint record, redo information, undo information.
UPS — cm. uninterruptable power supply.
user mode - пользовательский режим — непривилегированный режим
работы процессора, в котором исполняется код прикладных программ
Поток, исполняющийся в пользовательском режиме, может получить до-
ступ к системным ресурсам только посредством вызова системных серви-
сов. Ср. kernel mode.
valid page - действительная страница — виртуальная страница, распол<>"
женная в физической памяти и потому немедленно доступная. См. таклсс
invalid page, page.
VCN — см. virtual cluster numbers.
VDM — cm. virtual DOS machine.
view - проекция — часть объекта-секции, отображенная процессом в свое ад-
ресное пространство. Процесс может отобразить несколько проекций сек-
ции и даже перекрывающиеся проекции. Сад. также map, section object.
virtual address space - виртуальное адресное пространство — набор адре-
сов, доступных для потоков процесса. В Windows NT каждый процесс имеет
уникальное виртуальное адресное п|юстранство размером 2’-' байт (4 гига-
байт). Сад. также virtual memory.
virtual circuit - виртуальный контур — виртуальный коммуникационный
канал между двумя машинами. При помощи одного виртуального контура
можно установить несколько сетевых сессий.
virtual cluster numbers (VCNs) - виртуальные номера кластеров (VCN) —
числа, получающиеся в результате последовательной нумерации (начиная с
О) кластере», содержащих нерезидентные атрибуты файла. Для того, чтобы
найти кластеры файла на диске, NTFS увязывает VCN файла с I.CN. Ср. logical
cluster numbers (IjCNs); cm. также cluster, nonresident attribute.
virtual DOS machine (VDM) - виртуальная DOS-машина (VDM) — защи-
щенная подсистема, предоставляющая полную среду MS-DOS и консоль для
выполнения MS-DOS приложений. Одновременно может выполняться про-
извольное число VDM. См. также console.
virtual file - виртуальный файл — любой ресурс, доступ к которому осуще-
ствляется как к файлу. В исполнительной системе NT весь ввод—вывод вы-
полняется для виртуальных файлов, представляемых файловыми объекта-
ми, доступ к которым осуществляется с использованием описателей файлов.
См. также file objec t.
virtual memory (VM) - виртуальная память — логаческое представление
памяти, не обязательно совпадающее с ее физической структурой. См. так-
же virtual memory management.
virtual memory (VM) manager - диспетчер виртуальной памяти —
компонент исполнительной системы Windows NT, реализующий вирту-
альную память.
virtual memory management - управление виртуальной памятью — ре-
ализуется системой управления памятью, которая предоставляет процессу
большее адресное пространство, отображая виртуальные адреса процесса в
физические адреса, когда первые используются потоками процесса. Если фи-
зическая память оказывается переполненной, часть ее содержимого откачи-
вается на диск с возможностью последующей загрузки оттуда по требова-
нию. Управление виртуальной памятью позволяет1 программистам созда-
вать и запускать программы, использующие память большего объема, чем
физически имеется в компьютере. 'Гак как система виртуальной памят и уп-
равляет расположением данных в памяти, то каждому процессу’ может1 быть
выделено отдельное адресное пространство, защищенное от других про-
цессов. Сад. также тар и paging.
VM — сад. virtual memory.
АЧ1
volume ~ том — логический раздел лиска, создаваемый при его форматировд-
нии для некоторой ФС. Том NTFS может располагаться на нескольких дис-
ках. Си. также volume set.
volume file - файл тома — файл NTFS, содержащий имя тома, версию NTby
для которой этот том был отформатирован, а также бит изменений («dirty
bit»), указывающий, что имело место повреждение содержимого, котор<к.
должно быть исправлено утилитой Chkcl.sk.
volume set - набор томов — ряд свободных областей (до 32) на одном цЛц
более дисках, которые форматируются и используются NTFS как один том.
См. также volume.
Win32 API — 32-битный интерфейс прикладных программ (API), предназна-
ченный как для MS-DOS/Windows, так и для Windows NT. Содержи'! до-
полнительные возможности по сравнению с более ранними версиями
Windows API, в том числе средства, предоставляемые сложной ОС, защиту от
несанкционированного доступа и функции для отображения приложений
текстового режима в окне.
Windows NT — наиболее мощная из ОС семейства Windows. Вместе с Реп
Windows и 16-разрядной Windows* эта система позволяет выполнять
Windows-приложения на разных компьютерах, начиная от самых малень-
ких ноутбуков и заканчивая большими многопроцессорными рабочими
станциями и серверами. Windows NT, кроме того, может выполнять прило-
жения MS-DOS, POSIX и OS/2 при помощи серверов пользовательского
режима, называемых защищенными подсистемами. См. также protected
subsystem.
Windows on Win32 (WOW) — защищенная подсистема, выполняющаяся внут-
ри процесса виртуальной DOS—машины (VDM). Обеспечивает среду 16-
битной Windows, что позволяет запускать под Windows NT многие 16-бит-
ные Windows—приложения.
working set ~ рабочий набор — набор виртуальных страниц данного про-
цесса, которые всегда находятся в памяти.
workstation service ~ сервис рабочей станции — сетевой сервис, предос-
тавляющий интерфейс прикладных программ (API) пользовательского ре-
жима для управления редиректором Windows NT. См. также service.
WOW — см. W indows on W in32.
write-ahead logging - опережающее протоколирование — техник»
протоколирования, при которой записи журнала транзакций гарантирован-
но сбрасываются на диск до выполнения соответствующих модификаций
содержимого диска. См. также log file, logging, update record.
На момент написания книги не существовало крутой 32-разрядной ОС семейства Windows
Windows 95.
предметный указатель
русские термины
А
асинхронный..................... 113
атрибут......................... 354
— нерезидентный................. 356
_ объекта.........................39
— резидентный................... 355
аутентификация....................89
Б
бит изменений................... 365
битовая карта .................. 361
блок-схема Windows NT.............43
В
ввод-вывод
— асинхронный......... 244, 253, 262
— завершение................... 256
— обработка.................... 248
— - проекционный файловый... 180, 247
— синхронный................... 245
виртуальная
— память...................... 170
— DOS-машина................... 154
виртуал ы юе адресное npocrpai ютво... 171
восстанавливаемость........ 336, 363
вызов процедуры
— асинхронный.................. 113
— быстрый локальный............. 166
— локальный ............... 159, 162
— удаленный ............... 160, 301
вытесняющая многозадачность..... 150
Г
главная файловая таблица.....346, 353
д
Дескриптор виртуального адреса.. 109
Диспетчер
— ввода-вывода ................. 238
~~ виртуальной памяти........... 170
~ конфигурации.................. 313
— кэша..................... 247, 344
— учетных записей.............. 307
Домен.......................278, 309
— первичный.................... 309
драйвер.................... 242, 264
— виртуального устройства....... 156
— многослойный......... 244, 258, 269
— многоуровневый............337, 343
— однослойный.................. 251
— разработка................. 270
дуплексный набор............... 38O
Е
единица сжатия................. 390
Ж
журнал транзакций 344, 361, 363, 367, 369
3
замена секторов................ 382
запись
— контрольной точки.........369, 371
— модификации................ 369
— отложенная.................. 364
— сквозная.................... 366
— точная...................... 364
защита...........................23
— аудит.........................92
— аутентификационный пакет...... 138
— от несанкционированного доступа... 335
— регистрация пользователя.... 137
— список контроля доступа.... 90,91
— элемент контроля доступа......91
зеркализация диска............... 313
зеркальный набор................. 380
И
именованные каналы............. 305
имперсонация................... 306
индекс.........................- 347
индексация имен файлов......... 359
индексный буфер................ 357
интернационализация........... 56—57
интерфейс
— драйвера транспорта.......... 287
— режима ядра................. 367
- NetBIOS..................... 278
информация
— для отмены.................. 370
— для повтора................. 370
исключение..................... 215
- блочный обработчик........... 226
р генерация......................62
L- диспегчер................... 225
- обработчик................. 61-62
Р распределение................ 225
к структурная обработка..........60
сполиитсльная система ....... 36,41
- диспетчер виртуальной памяти...46
г диспетчер объектов.............45
L диспетчер процессов............45
- синхронизация......—......... 232
h локальный вызов процедуры......45
- система ввода-вывода.... 46, 54, 238
слой абстрагирования от
оборудования................ 37, 46
- справочный монитор защиты.....45
ядро.................. 37,46,205
iai гг времет ти................. 103
тастер........................... 338
тастерный множитель.............. 352
тмпилятор MIDI................... 303
тмпот тет гг GDI................. 150
депонент NT
| базовый сервис..................50
виртуальная память..............53
объект..........................50
। сессия регистра! щи ............47
файловая система................54
ип роллер домена................. 309
титическая секция .......... 63, 229
Цитирование атрибутов........... 152
двушка.......................... 216
тршрутизатор многосетевого
доступа....................... 292
угаданные.................. 353, 360
югопроцессорная сит тхро-
низация..................... 110, 229
югосетсвой UNC............. 292, 294
щель
клиент-сервер ...................34
объектная........... 34, 39, 240, 348
|ОС..............................34
реляционной базы данных....... 345
симметричной мультипроцессорной
обработки................... 34,40
льти процессорная обработка..... 201
— асимметричная....... .......... Ю
— симметричная............... 40, 2/>(;
Н
набор томов................... S-->
надежность.......................
номер
— логической последовательности... Зед
— кластера................. 352, 557
О
область
— протоколирования............. уод
— рестарта..................... 368
обработка
— асинхронная.................. 244
— мультипроцессорная.......... 27(т
— прерываний и исключений ....... 215
— прерываний.................21"’, 220
обработчик ловушки...........215, 216
обратный вызов................. 165
объект...........................39
— асинхронный вызов процедуры 207
— атрибут................ 66. 78, 339
— диспегчер......................67
— диспетчерский................ 207
— домен..........................79
— драйвер..................... 2(16
— защита..................... 87. 89
— имя............................76
— исполнительной системы.........67
— каталог........................77
— класс......................... 65
— маркер доступа.................89
— методы.........................85
— описатели......................82
— отложенный вызов
процедуры................ 207, 222
— параметр..................... 313
— поток..................... 108, 208
— прерывание................... 221
— проекция файла................ 1~
— процесс.................... 99, 208
— секция ............... 163, 177, 180
— сервисы........................78
— символическая связь............80
— состоят тие............... 111, 236
— ст руктура.....................72
— таблица объектов...............82
— тип........................ 65, 74
— уведомление питания......... 2.35
L удержание................................84
управление.............. 75,207
устройство.........-................... 266
__ учет использования ресурсов....85
файловый .................. 240, 248
ядра................ - 67, 20”
операция
_ асинхронная............................ 105
__ идемпотентная......................... 371
опережающее протоколирование...... 369
описатель файла.............. 240, 250
оповещения ....................... J J 3
опорная модель OS1....................... 278
ОС
— клиент-сервер .... ..................... 35
— многозадачная................... - 33
»- монолитная..................34
— послойная....................35
Отказоустойчивость............313, 337
откат.................................. 346
Открытая архитектура сети................ 291
Отложег н гое выч исление................ 185
отношение доверия........................ 309
Отрезок....................... 338, 356
II
цакет запроса............................ 267
пакетирование............................ 152
память
?- автоматическое урезание рабочего
набора................................ 194
I— виртуальная........................... 186
I •— действительные страницы ............ 173
। — зарезервированная ................... 175
защита............................... 181
— недействительные страницы....... 173
— отображение............................ 173
— переданная............................ 175
подкачка страниц...........173, 188
резервное хранилище................... 173
S— совместное использование.... 177, 184
— страницы............................... 173
управление............................ 175
^подсистема
— 16-разрядной Windows........ 124
взаимодействие друг с другом... 136
г— выполнение приложений................. 139
1— защиты .................... 89, 130
! — защищенная ............... 42, 124
— клиент-сервер.......................... 146
! — неотъемлемая.............. 43, 125
— среды.................. 43, 124. 12”
- MS-DOS.......................... 124
— Win32............... 124, 140, 141
порт сосдиг гения................ 161
поток.................... 33. 101, 339
— блок управления ................ 349
— высокоприоритетный.............. 212
— многозадачность.. ......... 102-103
— многопоточность................. 104
— переключение контекста .. 102. 207, 213
— перемет и того приоритета....... 212
— прост оя........................ 213
— управления.................... 33,96
прерывание....................215, 254
— асинхронного вызова процедур .. 224
— диспетчерское............... 222
— отложенного вызова процедуры.. 222
— прог раммное.................... 221
— таблица распределения....... 220
— типы........................ 217-218
проецируемый файл ................ 180
производительность..................30
промах кэша................... 344
пространство имен файлов...... 393
протокол...................... 277
— IPX/SPX..................... 298
- NetBEUI..................... 297
— TCP/IP...................... 297
протоколирование.............. 367
проход
— анализа......................... 373
— отмены . 375
— повтора......................... 374
процедура обслуживания
прерываний.................. 255
процесс.................. 33, 95, 96
— адресное пространство...... 96, 186
— базовая структура............... 118
— базовый приоритет............... 100
— группа .......................... НО
— дерево ......................... 116
— дочерний.......— ............ 116
— клиентский..................... 119
— многопоточный................... 105
— г табор ресурсов..................98
— неправильное использование..... 121
— порты исключений и отладки----- 100
— процессорное сродство........... 209
— собственная память.............. 182
— структура................... 95, 114
р
разрешение имен.................. 290
распределш ше прерываний......... 217
расширяемость.....................25
редиректор.............. 277, 285, 286
реестр.......................... .313
режим
— пользовательский........... 34, 96
— ядра..................... 34, 96
С
сбой питания................. 235, 273
сброс кэша...................... 365
сервер....................... 278, 288
сервис
— журнала транзакций............ 344
— оповещений ................... 285
— сервера....................... 285
— сообщений..................... 285
сжатие
— механизм...................... 392
— обычных данных................ 390
— разреженного файла............ 388
сменный диск.................... 341
совместимость.....................29
состояние «свободен»............ 263
спин-блокировка............. 231, 300
средство отложенной записи ..... 345
стратегия
— замещения ................... 193
— размещения................... 193
— считывания................... 192
Т
таблица
— измененных страниц............ 373
— определения атрибутов......... 362
— транзакций.................... 373
том............................. 351
транзакция.............. 346, 363, 367
— подтверждение................. 370
Ф
файл
— виртуальный................... 240
— загрузочный................... 361
— имя........................... 393
— плохих кластеров.............. 362
— подкачки...................... 175
— ссылка ....................... 353
— тома.......................... 362
фрагментация.................. Зз§
фрейм
— действительный.............. Н)у
— измененный ................ 1<у?
— обнуленный................ ]»)?
— плохой...................... 1<р
— резервный................... Ц)7
— свободный.................... цр
Ч
чередование дисков...... 314, З^в. узд
Э
экстент....................... 35^
Я
ядро
— диспетчер.................. 207
— задачи..................... 206
— очередь готовности диспетчера .. 211
— перепланировка потоков..... 214
— планирование потоков....... 207
— приоритеты планирования ... 211
Английские термины
А
API
— ввода-вывода Win32 ......... 282
— именованных каналов......... 282
— сетевой Win32............... 282
— NetBIOS..................... 283
— Windows Sockets............. 283
В
b+ дерево.................. 347, 360
L
IAN Manager................ 278, 288
M
MS-NET........................ 277
N
NDIS.......................... 298
S
STREAMS ...................... 298
U
UNICODE................. 58, 340, 395
W
Windows на Win32 .............. 15
Хелен Кастер (Helen Custer) с отличием окончила Канзасский
университет, получив степень бакалавра гуманитарных наук
по информатике (computer science), английскому языку и
психологии. Свою восьмилетнюю карьеру профессиональ-
ного писателя она начала как соавтор книги “Learning Z-BASIC
on Health/Zenith Z-100". Прежде чем присоединиться к группе
разработчиков Windows NT и написать эту книгу, Хелен рабо-
тала в Digital Equipment Corporation, где писала руководства
по С, документацию по операционным системам, а также за-
нималась разработкой средств документирования. Ее статьи
печатались в журналах С User's Journal, Windows/DOS Develo-
per's Journal (бывший Tech Specialist) и Microsoft Systems Journal.
Хелен Кастер
Основы Windows NT и NTFS
Научный консультант Ф. В. Зубанов
Переводчик Д. Г. Новоселов
Редактор Е. А. Краснушкина
Технический редактор Н. Г. Тимченко
Оригинал-макет выполнен с использованием
издательской системы Adobe PageMaker 6.0
Компьютерный дизайн В. Б. Хильченко
Главный редактор А. И. Козлов
Главный менеджер М. И. Царейкин
Подготовлено издательским отделом "Русская Редакция" ТОО "Channel Trading Ltd."
Генеральный директор В. В. Телушкин
Лицензия ЛР № 090082 от 14.04.9-1 г. Подписано и печать 14.12.00 г. Тираж 10 000 экз.
"РУССКАЯ РЕДАКЦИЯ" ПРЕДСТАВЛЯЕТ
Переводы бестселлеров Microsoft Press
Microsoft Press. Ресурсы MicrosoftWindows 95
Стефен Нелсон. Путеводитель no Internet для Windows 95
Стефен Нелсон. Путеводитель no MicrosoftWindows 95
Microsoft Press. Толковый словарь по вычислительной технике
Брюс Мак-Кинни. Крепкий орешек Visual Basic4, имеете с CD
Хелен Кастер. Основы Windows NT и NTFS
Льюис Кан, Лаура Логан. Мой узел Web. вместе с CD
Microsoft Press. Компьютерные сети. Учебный курс, вместе с CD
Дэвид Дж. Круглински. Основы Visual C++, версия 4.0. вместе с CD
Ронни Шушан. Дон Райт. Дизайн и компьютер: Page Maker 6 всем и каждому
(I квартал 1997г.). вместе с CD
Дэвид Чапел. Глубины ActiveX и OLE (1 квартал 1997г.)
Стефен Р. Дэвис. Руководство no MS Visual Java++ (1 квартал 1997г.). вместе с CD
Авторские издания
Ф. Зубанов. Windows NT—
выбор «профи»
Г. Бугрименко, Е. Рыбкин.
Виражи 3D Studio
В. Биллиг, И. Мусикаев.
Visual C++4.
Книга для программистов
Совместные издания
Л. Пинтер, Дж. Пинтер.
Visual FoxPro: уроки программирования
МакЦентр.
Макинтош для пользователя
А. Горев. Разработка приложений
в Visual FoxPro 3.0
Бестселлер 1996 г.
Билл 1ейтс. Дорога в будущее
Первая книга легендарного
основателя и главы
корпорации MKmsoit
опт. (095) 14? 0571
роэн. (096) 275-131Д
Рассылка почтой:
АОЗТ «Олег Аск ос и
тел. Сг*гб)298- )1?
Более подробную информацию Вы можете найти на Web-сервере
издательства «Инфоарт»: http://www.ritmpress.ru в разделе «Информация: Книги».
Ваши отзывы и пожелания направляйте по адресу:
121087, Москва, ул. Заречная, 15/7, к. 1 или e-matt: rusedit@online.ru.
И.ШСШ РЕШИМ
Издательский отдел TOO "Channel Trading Ltd."
основы
у 1^1 I
И
Microsoft1*
WindowsNT
и UTK
Niro
Взгляд Изнутри на дизайн, концепцию, архитектуру
и будущее Microsoft Windows NT
В названии Windows NT аббревиатура NT означает “новая технология”.
Это 32-разрядная операционная система фирмы Microsoft нового поколения
работающая на многих аппаратных платформах. Несмотря на радикальные
изменения в архитектуре, Windows NT обеспечивает потрясающую обратную
совместимость. Чтобы разобраться в возможностях этой ОС, необходимо
понять ее основные принципы. В Windows NT на первый план вышли
некогда экзотические концепции: архитектура микроядра, защита объектов,
встроенная поддержка сетей и клиент-серверные подсистемы..
"Основы Windows NT” написаны участницей команды разработчиков этой ОС.
Автор рассказывает о целях проекта и модели архитектуры Windows NT.
Подробно рассмотрены:
клиент-серверные защищенные подсистемы;
ядро NT;
мене/Окер виртуальной"памяти;
управление объектами;
процессы и потоки;
ввод-вывод и файловые системы;
направления развития и многое другое.
Русское издание включает в себя перевод двух книг. Вторая — "Основы
файловой системы NTFS” — дополняет “Основы Windows NT" и посвящена
новой файловой системе, устанавливающей стандарт надежности
и производительности. Подробно описаны структура NTFS, сжатие
данных и способы восстановления после сбоя системы.
В книгу внесены изменения и дополнения, учитывающие современное
состояние системы (в т. ч. версии Windows NT 4.0).
МююзсЛ Press Я11КСШЩ1Ц11