Алгоритм планирования реализованный в windows nt можно охарактеризовать как
19) Опишите смешанный алгоритм планирования в ос Windows nt.
Во многих операционных системах алгоритмы планирования построены с использованием как концепции квантования, так и приоритетов. Например, в основе планирования лежит квантование, но величина кванта и/или порядок выбора потока из очереди готовых определяется приоритетами потоков. Именно так реализовано планирование в системе Windows NT, в которой квантование сочетается с динамическими абсолютными приоритетами. На выполнение выбирается готовый поток с наивысшим приоритетом. Ему выделяется квант времени. Если во время выполнения в очереди готовых появляется поток с более высоким приоритетом, то он вытесняет выполняемый поток. Вытесненный поток возвращается в очередь готовых, причем он становится впереди всех остальных потоков имеющих такой же приоритет.
20)Перечислите события, требующие перераспределения процессорного времени и поясните действия планировщика ос в каждом случае.
1-прерывание таймера(конец кванта)-планировщик переводит задачу или поток в состояние канта что бы получить след. Квант
2-активная задача выполнила сис. вызов –запрос на вод-вывод, который в настоящий момент занят, переводит в состояние ожидания и выполняет перепланировку
3-активная задача выполнила сис.вызов связанный с освобождением ресурсов-планировщик получает ресурс и переводит в состояние готовности.
4-внешнее аппаратное прерывание, сигнализирующая о завершении УВМ операций в.-в.,в этом случае планировщик переводит задачу в очередь готовых и производит перепланировку
5-внутриние прерывание сигнала-планировщик снимает задачу и производит перепланировку.
21) Опишите моменты перепланировки в среде ос рв.
При возникновении событий, требующих перераспределения процессорного времени, планировщик ОС просматривает очереди задач и решает, какая задача будет выполняться следующей. Также существует ряд других событий, часто связанных с системными вызовами, требующие перепланировки. Например, запрос пользователя или приложения на создание задачи. В системах РВ для обработки статического расписания планировщик активизируется по требованию таймера (32 мс). После каждого прерывания планировщик просматривает расписание и проверяет, не пора ли переключить задачи.
22)Как осуществляются диспетчеризация и учёт приоритетов прерываний в ос?
При возникновении приоритета диспетчер прерываний вызывается первым, запрашивает не на долго все прерывания, выясняет причину и источник прерывания, затем сравнивается назначенный данному источнику приоритет с текущим приоритетом команд и если новый выше текущего то запускается обработчик и в этот момент проц. уже может выполнять инструкции другого прерывания. Если приоритет нового запроса выше текущего то выполнение текущего приостанавливается, иначе в очередь помещается обработчик нового запроса.
23) Как работает диспетчер прерываний?
Диспетчер прерывания является важной функцией реализованных во всех мультипроцессорных ос и в общем случае реализовывается двух уровневым механизмом работ: верхний уровень выполняется диспетчером приоритетов, а в оставшимся проц. время распределяется другим диспетчером потоков.
8. Процессы и нити. Алгоритмы планирования
Адресное пространство каждого процесса защищено от вмешательства в него любого другого процесса. Это обеспечивается механизмами виртуальной памяти. Операционная система, конечно, тоже защищена от прикладных процессов. Чтобы выполнить какую-либо процедуру ОС или прочитать что-либо из ее области памяти, нить должна выполняться в режиме ядра. Пользовательские процессы получают доступ к функциям ядра посредством системных вызовов. В пользовательском режиме выполняются не только прикладные программы, но и защищенные подсистемы Windows NT.
Напомним, что нить является выполняемой единицей, которая располагается в адресном пространстве процесса и использует ресурсы, выделенные процессу. Подобно процессу нить в Windows NT реализована в форме объекта и управляется менеджером объектов.
Кроме перечисленных, имеются и некоторые другие атрибуты.
Как видно из перечня, многие атрибуты объекта-нити аналогичны атрибутам объекта-процесса. Весьма сходны и сервисные функции, которые могут быть выполнены над объектами-процессами и объектами-нитями: создание, открытие, завершение, приостановка, запрос и установка информации, запрос и установка контекста и другие функции.
Алгоритм планирования процессов и нитей.В Windows NT реализована вытесняющая многозадачность, при которой операционная система не ждет, когда нить сама захочет освободить процессор, а принудительно снимает ее с выполнения после того, как та израсходовала отведенное ей время (квант), или если в очереди готовых появилась нить с более высоким приоритетом. При такой организации разделения процессора ни одна нить не займет процессор на очень долгое время.
Рис. 31. Граф состояний нити
Каждый раз, когда необходимо выбрать нить для выполнения, диспетчер прежде всего просматривает очередь готовых нитей реального времени и обращается к другим нитям, только когда очередь нитей реального времени пуста. Большинство нитей в системе попадают в класс нитей с переменными приоритетами, диапазон приоритетов которых от 0 до 15. Этот класс имеет название «переменные приоритеты» потому, что диспетчер настраивает систему, выбирая (понижая или повышая) приоритеты нитей этого класса.
Использование динамических приоритетов, изменяющихся во времени, позволяет реализовать адаптивное планирование, при котором не дискриминируются интерактивные задачи, часто выполняющие операции ввода-вывода и недоиспользующие выделенные им кванты. Если нить полностью исчерпала свой квант, то ее приоритет понижается на некоторую величину. В то же время приоритет нитей, которые перешли в состояние ожидания, не использовав полностью выделенный им квант, повышается. Приоритет не изменяется, если нить вытеснена более приоритетной нитью.
Для того, чтобы обеспечить хорошее время реакции системы, алгоритм планирования использует наряду с квантованием концепцию абсолютных приоритетов. В соответствии с этой концепцией при появлении в очереди готовых нитей такой, у которой приоритет выше, чем у выполняющейся в данный момент, происходит смена активной нити на нить с самым высоким приоритетом.
В многопроцессорных системах при диспетчеризации и планировании нитей играет роль их процессорная совместимость: после того, как ядро выбрало нить с наивысшим приоритетом, оно проверяет, какой процессор может выполнить данную нить и, если атрибут нити «процессорная совместимость» не позволяет нити выполняться ни на одном из свободных процессоров, то выбирается следующая в порядке приоритетов нить.
Простая модель планировщика ОС
Не так давно пытался найти здесь какую-нибудь информацию о планировщике Windows и к своему удивлению не нашёл ничего конкретного о планировщиках вообще, поэтому решил запостить вот этот пример планировщика, надеюсь кому-то он окажется полезен. Код написан на Turbo Pascal со вставками ассемблера 8086.
Что собственно планирует планировщик?
Алгоритмы планирования
Критические секции
C процессорным временем или стеком вроде бы всё просто, а что если потоку требуется например напечатать на принтере котёнка? А что если таких потоков два? При невытесняющей многозадачности всё пройдёт как по маслу: один поток отпечатает котёнка, завершится и отдаст управление планировщику, который позволит печатать второму потоку. Но если многозадачность вытесняющая, планировщик может переключить потоки в момент, когда те ещё не завершили печать и получится что-то вроде этого: 
Чтобы такого не происходило вводится механизм критических секций. Поток, которой хочет занять некий неразделяемый ресурс, сообщает об этом планировщику. Если ресурс ещё не занят другим потоком — планировщик разрешает потоку продолжить работу, а сам помечает ресурс, как занятый. Если же ресурс занят — поток помещается в очередь, где он ожидает, когда тот освободится. По завершении работы с таким ресурсом поток должен сообщить планировщику о том что ресурс теперь могут использовать другие потоки. Эти два действия: попытка захватить ресурс и сообщение о прекращении работы с ним называются критическими скобками. Кстати при неумелой их расстановке может возникнуть ситуация взаимной блокировки потоков, которая не всегда хорошо и быстро диагностируется и может вызвать неиллюзорный батхёрт у разработчика и пользователя уже после релиза продукта.
Взаимная блокировка
Допустим у нас есть неразделяемые ресурсы А и Б и потоки Х, Y, которые хотят задействовать эти ресурсы. Если некий криворукий недостаточно компетентный программист расставит критические скобки вот так:
…
Поток X
Занять Ресурс(А)
Занять Ресурс(Б)
…
Отдать Ресурс(А)
Отдать Ресурс(Б)
Поток Y
Занять Ресурс(Б)
Занять Ресурс(А)
…
Отдать Ресурс(Б)
Отдать Ресурс(А)
через некоторое время возникнет вот такая ситуация: 
Сладенькое
Ну и собственно то ради чего это всё писалось. Как уже было сказано код нашего планировщика будет выполнен на языке Turbo Pascal.
Механизм критических секций реализован в процедурах EnterCritical(), LeaveCritical(). Вспомним ещё раз: чтобы войти в критическую секцию — нужно проверить не занята ли она, и по результату — либо занять её и разрешить потоку ей пользоваться, либо поставить поток в очередь и передать управление кому-то другому.
C LeaveCritical() вроде бы и так всё ясно:
Сама процедура переключения потоков написана с использованием ассемблерных вставок, поэтому можно увидеть момент переключения потоков от одного к другому с точностью до машинной команды:
Сама процедура скомпилирована с директивой interrupt, то есть является обработчиком прерывания. Которое может быть спровоцировано как аппаратно, так и программно вызовом int 08h, вот так:
Так же необходимо описать сами процедуры регистрации, включения и остановки потоков. Если кому-то интересно — можно посмотреть в исходниках процедуры RegistrThread, RunThread, StopThread.
Вот и всё! Наш планировщик готов.
Исходники вместе примером многопоточной программы написаной под этот планировщих и досовским турбиком можно скачать здесь. Можно поиграться и посмотреть как по разному будут выполняться потоки при вытесняющей и невытесняющей многозадачности (процедура ExecuteRegisterThreads(true/false)), смоделировать ситуацию взаимной блокировки и убедиться в том, что она не всегда диагностируема (я однажды минуту ждал пока возникнет дедлок).
Запускать в системах новее Win98 советую из под DOSbox.
Алгоритм планирования реализованный в windows nt можно охарактеризовать как
Структурно Windows NT может быть представлена в виде двух частей: часть операционной системы, работающая в режиме пользователя, и часть операционной системы, работающая в режиме ядра (рисунок 8.1).
Рис. 8.1. Структура Windows NT
Ядро работает в привилегированном режиме и никогда не удаляется из памяти. Обратиться к ядру можно только посредством прерывания. Ядро расположено над уровнем аппаратных абстракций (Hardware Abstraction Level HAL), который концентрирует в одном месте большую часть машинно-зависимых процедур. HAL располагается между NT executive и аппаратным обеспечением и скрывает от системы такие детали, как контроллеры прерываний, интерфейсы ввода/вывода и механизмы взаимодействия между процессорами. Такое решение позволяет легко переносить Windows NT с одной платформы на другую путем замены только слоя HAL.
При создании NT разработчики руководствовались задачами улучшения производительности и сетевых возможностей, а также требованием поддержки определенного набора прикладных сред. Эта цель была достигнута продуманным разделением функций между модулями ядра и остальными модулями. Например, передача данных в файловую систему и по сети производится быстрее в пространстве ядра, поэтому внутри ядра NT выделены буфера для небольших по объему (от 16 до 32 Кб) операций чтения и записи, являющихся типичными для приложений клиент-сервер и распределенных приложений. Размещение этих функций ввода-вывода внутри ядра, может, и портит академическую чистоту микроядра NT, но соответствует цели создания NT.
Защищенные подсистемы Windows NT работают в пользовательском режиме и создаются Windows NT во время загрузки операционной системы. Сразу после создания они начинают бесконечный цикл своего выполнения, отвечая на сообщения, поступающие к ним от прикладных процессов и других подсистем. Среди защищенных подсистем можно выделить подкласс, называемый подсистемами окружения. Подсистемы окружения реализуют интерфейсы приложений операционной системы (API). Другие типы подсистем, называемые интегральными подсистемами, исполняют необходимые операционной системе задачи. Например, большая часть системы безопасности Windows NT реализована в виде интегральной подсистемы, сетевые серверы также выполнены как интегральные подсистемы.
Каждая защищенная подсистема работает в режиме пользователя, вызывая системный сервис NT executive для выполнения привилегированных действий в режиме ядра. Сетевые серверы могут выполняться как в режиме пользователя, так и в режиме ядра, в зависимости от того, как они разработаны.
Подсистемы связываются между собой путем передачи сообщений. Когда, например, пользовательское приложение вызывает какую-нибудь API-процедуру, подсистема окружения, обеспечивающая эту процедуру, получает сообщение и выполняет ее либо обращаясь к ядру, либо посылая сообщение другой подсистеме. После завершения процедуры подсистема окружения посылает приложению сообщение, содержащее возвращаемое значение. Посылка сообщений и другая деятельность защищенных подсистем невидима для пользователя.
Таким образом, реализация частей ОС в виде серверов, выполняющихся в режиме пользователя, является важнейшей частью проекта Windows NT и оказывает глубокое воздействие на все функционирование системы.
Множественные прикладные среды
При разработке NT важнейшим рыночным требованием являлось обеспечение поддержки по крайней мере двух уже существующих программных интерфейсов OS/2 и POSIX, а также возможности добавления других API в будущем.
Заметим, что для того, чтобы программа, написанная для одной ОС, могла быть выполнена в рамках другой ОС, недостаточно лишь обеспечить совместимость API. Кроме этого, необходимо обеспечить ей «родное» окружение: структуру процесса, средства управления памятью, средства обработки ошибок и исключительных ситуаций, механизмы защиты ресурсов и семантику файлового доступа. Отсюда ясно, что поддержка нескольких прикладных программных сред является очень сложной задачей, тесно связанной со структурой операционной системы. Эта задача была успешно решена в Windows NT, при этом в полной мере был использован опыт разработчиков ОС Mach из университета Карнеги-Меллона, которые смогли в своей клиент-серверной реализации UNIX’а отделить базовые механизмы операционной системы от серверов API различных ОС.
Windows NT поддерживает пять прикладных сред операционных систем: MS-DOS, 16-разрядный Windows, OS/2 1.x, POSIX и 32-разрядный Windows (Win32). Все пять прикладных сред реализованы как подсистемы окружения. Каждая работает в собственном защищенном пользовательском пространстве. Подсистема Win32 обеспечивает поддержку дисплея, клавиатуры и мыши для четырех оставшихся подсистем.
Подсистемы OS/2 и POSIX построены по-другому. В качестве полноценных подсистем NT они могут взаимодействовать с подсистемой Win32 для получения доступа к вводу и выводу, но также могут обращаться непосредственно к исполнительной системе NT за другими средствами операционной системы. Подсистема OS/2 может выполнять многие имеющиеся приложения OS/2 символьного режима, включая OS/2 SQL Server, и поддерживает именованные каналы и NetBIOS.
Однако возможности подсистемы POSIX весьма ограничена, несмотря на непосредственный доступ ее к службам ядра. Приложения POSIX должны быть откомпилированы специально для Windows NT. NT не поддерживает двоичный код, предназначенный для других POSIX-совместимых систем, таких как UNIX. К тому же подсистема POSIX NT не поддерживает непосредственно печать, не поддерживает сетевой доступ, за исключением доступа к удаленным файловым системам, и не поддерживает многие средства Win32, например, отображение на память файлов и графику.
Рис. 8.2. Реализация множественных прикладных сред в Windows NT
На рисунке 8.2 показана структура, обеспечивающая в Windows NT поддержку множественных прикладных сред.
NT executive выполняет базовые функции операционной системы и является той основой, на которой подсистемы окружения реализуют поддержку своих приложений. Все подсистемы равноправны и могут вызвать «родные» функции NT для создания соответствующей среды для своих приложений.
Каждая подсистема окружения имеет свое представление о том, что такое, например, процесс или описатель файла, поэтому структуры данных, используемые в каждом окружении, могут не совпадать. Следовательно, как только подсистема Win32 передала прикладной процесс другой подсистеме окружения, данное приложение становится клиентом этой подсистемы вплоть до завершения процесса. При этом подсистема Win32 перенаправляет входные сообщения от пользователя этому приложению, а также отображает вывод приложения на экране.
Объектно-ориентированный подход
Наиболее фундаментальное отличие между объектом и обыкновенной структурой данных заключается в том, что внутренняя структура данных объекта скрыта от наблюдения. Вы должны вызвать объектную функцию для того, чтобы получить данные из объекта или поместить данные в объект. Вы не можете непосредственно изменять данные, находящиеся внутри объекта. Это отделяет средства реализации объекта от кода, который только использует его, такая техника позволяет легко изменять в последствии реализацию объектов.
Не все структуры данных в NT executive являются объектами. Объектами сделаны только такие данные, которые нужно разделять, защищать, именовать или делать видимыми для программ пользовательского режима ( с помощью системных функций). Структуры, которые используются только одним компонентом executive для выполнения внутренних функций, не являются объектами.
Несмотря на всестороннее использование объектов для представления разделяемых ресурсов, Windows NT не является объектно-ориентированной системой в строгом смысле. Большая часть кода операционной системы написана на С с целью обеспечения переносимости. Несмотря на то, что С не поддерживает непосредственно объектно-ориенти-
рованные конструкции, такие как динамическое связывание типов данных, полиморфные функции или наследование классов, эти инструментальные средства были использованы из-за их широкой распространенности.
Процессы пользовательского режима, включая подсистемы окружения, должны иметь описатель объекта перед тем, как их нити смогут использовать этот объект. Использование описателей для работы с системными ресурсами не является новой идеей. Например, библиотеки С и Паскаля (а также других языков) возвращают описатели для открытых файлов. Аналогично приложения Win32 используют различные типы описателей для управления окнами, курсором мыши, иконками. В обоих случаях описатели служат косвенными указателями на системные ресурсы; эта косвенность предохраняет прикладные программы от рутинной работы непосредственно с системными структурами данных.
Кроме заголовка объекта, каждый объект имеет тело объекта, формат и содержание которого уникально определяется типом этого объекта; у всех объектов одного и того же типа одинаковый формат тела. При создании объекта исполнительная часть может оперировать данными в телах всех объектов этого типа.
Процессы и нити
Адресное пространство каждого процесса защищено от вмешательства в него любого другого процесса. Это обеспечивается механизмами виртуальной памяти. Операционная система, конечно, тоже защищена от прикладных процессов. Чтобы выполнить какую-либо процедуру ОС или прочитать что-либо из ее области памяти, нить должна выполняться в режиме ядра. Пользовательские процессы получают доступ к функциям ядра посредством системных вызовов. В пользовательском режиме выполняются не только прикладные программы, но и защищенные подсистемы Windows NT.
Напомним, что нить является выполняемой единицей, которая располагается в адресном пространстве процесса и использует ресурсы, выделенные процессу. Подобно процессу нить в Windows NT реализована в форме объекта и управляется менеджером объектов.
Кроме перечисленных, имеются и некоторые другие атрибуты.
Как видно из перечня, многие атрибуты объекта-нити аналогичны атрибутам объекта-процесса. Весьма сходны и сервисные функции, которые могут быть выполнены над объектами-процессами и объектами-нитями: создание, открытие, завершение, приостановка, запрос и установка информации, запрос и установка контекста и другие функции.
Алгоритм планирования процессов и нитей
В Windows NT реализована вытесняющая многозадачность, при которой операционная система не ждет, когда нить сама захочет освободить процессор, а принудительно снимает ее с выполнения после того, как та израсходовала отведенное ей время (квант), или если в очереди готовых появилась нить с более высоким приоритетом. При такой организации разделения процессора ни одна нить не займет процессор на очень долгое время.
Рис. 8.3. Граф состояний нити
Каждый раз, когда необходимо выбрать нить для выполнения, диспетчер прежде всего просматривает очередь готовых нитей реального времени и обращается к другим нитям, только когда очередь нитей реального времени пуста. Большинство нитей в системе попадают в класс нитей с переменными приоритетами, диапазон приоритетов которых от 0 до 15. Этот класс имеет название «переменные приоритеты» потому, что диспетчер настраивает систему, выбирая (понижая или повышая) приоритеты нитей этого класса.
Использование динамических приоритетов, изменяющихся во времени, позволяет реализовать адаптивное планирование, при котором не дискриминируются интерактивные задачи, часто выполняющие операции ввода-вывода и недоиспользующие выделенные им кванты. Если нить полностью исчерпала свой квант, то ее приоритет понижается на некоторую величину. В то же время приоритет нитей, которые перешли в состояние ожидания, не использовав полностью выделенный им квант, повышается. Приоритет не изменяется, если нить вытеснена более приоритетной нитью.
Для того, чтобы обеспечить хорошее время реакции системы, алгоритм планирования использует наряду с квантованием концепцию абсолютных приоритетов. В соответствии с этой концепцией при появлении в очереди готовых нитей такой, у которой приоритет выше, чем у выполняющейся в данный момент, происходит смена активной нити на нить с самым высоким приоритетом.
В многопроцессорных системах при диспетчеризации и планировании нитей играет роль их процессорная совместимость: после того, как ядро выбрало нить с наивысшим приоритетом, оно проверяет, какой процессор может выполнить данную нить и, если атрибут нити «процессорная совместимость» не позволяет нити выполняться ни на одном из свободных процессоров, то выбирается следующая в порядке приоритетов нить.
Сетевые средства
Средства сетевого взаимодействия Windows NT направлены на реализацию взаимодействия с существующими типами сетей, обеспечение возможности загрузки и выгрузки сетевого программного обеспечения, а также на поддержку распределенных приложений.
Сначала редиректор и сервер были написаны на ассемблере и располагались над существующим системным программным обеспечением MS-DOS. Новые редиректор и сервер встроены в Windows NT, они не зависят от архитектуры аппаратных средств, на которых работает ОС. Они написаны на С и выполнены как загружаемые драйверы файловой системы, которые могут загружаться или выгружаться в любое время. Они также могут сосуществовать с редиректорами и серверами других производителей.
Реализация редиректора и сервера как драйверов файловой системы делают их частью NT executive. Следовательно, они имеют доступ к специализированным интерфейсам, которые менеджер ввода-вывода обеспечивает для драйверов. Эти интерфейсы, в свою очередь, были разработаны с учетом нужд сетевых компонент. Доступ к интерфейсам драйверов плюс возможности непосредственного вызова кэш-менеджера дают значительный вклад в повышение производительности редиректора и сервера. Многоуровневая модель драйверов менеджера ввода-вывода отражает многоуровневую модель сетевых протоколов. Так как редиректор и сервер являются драйверами, то они могут быть размещены на верхнем уровне, под которым располагаются все необходимые драйверы транспортных протоколов. Такая структура обеспечивает модульность сетевых компонент и создает эффективный путь от уровня редиректора или сервера вниз к транспортному и физическому уровням сети.
Сетевой редиректор обеспечивает средства, необходимые одному компьютеру Windows NT для доступа к файлам и принтерам другого компьютера. Так как он поддерживает SMB-протокол, то он работает с существующими серверами MS-NET и LAN Manager, обеспечивая доступ к системам MS-DOS, Windows и OS/2 из Windows NT. Механизмы безопасности обеспечивают защиту данных Windows NT, разделяемых по сети, от несанкционированного доступа.
Редиректор имеет одну основную задачу: поддержку распределенной файловой системы, которая ведет себя подобно локальной файловой системе, хотя и работает через ненадежную среду (сеть). Когда связь отказывает, редиректор ответственен за восстановление соединения, если это возможно, или же за возврат кода ошибки, чтобы приложение смогло повторить операцию.
Подобно другим драйверам файловой системы, редиректор должен поддерживать асинхронные операции ввода-вывода, если они вызываются. Когда пользовательский запрос является асинхронным, то редиректор должен вернуть управление немедленно, независимо от того, завершилась ли удаленная операция ввода-вывода или нет. При этом редиректор выполняется в контексте этой нити. Вызывающая нить должна продолжить свою работу, а редиректор должен ждать завершения запущенной операции. Есть два варианта решения этой проблемы: или редиректор сам создает новую нить, которая будет ждать, или он может передать эту работу уже готовой нити, существующей в системе. В Windows NT реализован второй вариант.
Редиректор отправляет и получает блоки SMB для выполнения своей работы. Протокол SMB является протоколом прикладного уровня, включающим сетевой уровень и уровень представления.
Как и редиректор, сервер Windows NT на 100% совместим с существующими SMB-протоколами MS-NET и LAN Manager. Эта полная совместимость позволяет серверу обрабатывать запросы, исходящие не только от систем Windows NT, но и от других систем, работающих с программным обеспечением LAN Manager. Как и редиректор, сервер выполнен в виде драйвера файловой системы.
Главное из них состоит в том, что драйвер реализован в среде NT executive и может вызывать кэш-менеджер NT непосредственно, что оптимизирует передачу данных. Например, когда сервер получает запрос на чтение большого количества данных, он вызывает кэш-менеджер для определения места расположения этих данных в кэше (или для загрузки этих данных в кэш, если их там нет) и для фиксации данных в памяти. Затем сервер передает данные непосредственно из кэша в сеть, минуя доступ к диску. Аналогично, при запросе на запись данных сервер вызывает кэш-менеджер для резервирования места для поступающих данных. Затем сервер пишет данные непосредственно в кэш. Записывая данные в кэш, сервер возвращает управление клиенту гораздо быстрее; затем кэш-менеджер записывает данные на диск в фоновом режиме (используя страничные средства менеджера виртуальной памяти).
Будучи драйвером файловой системы, сервер несколько более гибок по сравнению с его реализацией в виде процесса. Например, он может регистрировать функции завершения ввода-вывода, что позволяет ему получать управление немедленно после завершения работы драйверов нижнего уровня. Хотя сервер Windows NT реализован как драйвер файловой системы, другие серверы могут быть реализованы и как драйверы, и как серверные процессы.
Асинхронные вызовы обрабатываются сервером аналогично, с использованием пула рабочих нитей.
И редиректоры, и серверы, и транспортные драйверы могут быть в любое время загружены и выгружены.
Для доступа к другим типам сетей в Windows NT, помимо встроенного, могут загружаться дополнительные редиректоры. Специальные компоненты Windows NT решают, какой редиректор должен быть вызван для обслуживания запроса на удаленный ввод-вывод. За последние десятилетия получили распространение различные протоколы передачи информации по сети. И хотя Windows NT поддерживает не все эти протоколы, она, по крайней мере, разрешает включать их поддержку.
После того, как сетевой запрос достигает редиректора, он должен быть передан в сеть. В традиционной системе каждый редиректор жестко связан с определенным транспортным протоколом. В Windows NT поставлена задача гибкого подключения того или иного транспортного протокола, в зависимости от типа транспорта, используемого в другой сети. Для этого во всех редиректорах нижний уровень должен быть написан в соответствии с определенными соглашениями, которые и определяют единый программный интерфейс, называемый интерфейсом транспортных драйверов (TDI).
Сетевые адаптеры поставляются вместе с сетевыми драйверами, которые раньше часто были рассчитаны на взаимодействие с определенным типом транспортного протокола. Так как Windows NT позволяет загружать драйверы различных транспортных протоколов, то производители сетевых адаптеров, использующие такой подход, должны были писать различные варианты одного и того же драйвера, рассчитанные на связь с разными протоколами транспортного уровня.
Чтобы помочь производителям избежать этого, Windows NT обеспечивает интерфейс и программную среду, называемые «спецификация интерфейса сетевого драйвера» (NDIS), которые экранируют сетевые драйверы от деталей различных транспортных протоколов. Самый верхний уровень драйвера сетевого адаптера должен быть написан в соответствии с рекомендациями NDIS. В этом случае пользователь может работать с сетью TCP/IP и сетью NetBEUI (или DECnet, NetWare, VINES и т.п.), используя один сетевой адаптер и один сетевой драйвер. Среда NDIS использовалась в сетях LAN Manager, но для Windows NT она была обновлена.
Через свою нижнюю границу драйвер сетевого адаптера обычно взаимодействует непосредственно с адаптером или адаптерами, которые он обслуживает. Драйвер сетевого адаптера, реализованный для среды NDIS, управляет адаптером не непосредственно, а использует для этого функции, предоставляемые NDIS (например, для запуска ввода-вывода или обработки прерываний). Таким образом, среда NDIS образует некую оболочку, которая позволяет достаточно просто переносить драйверы сетевых адаптеров из одной ОС в другую. NDIS позволяет сетевым драйверам не содержать встроенных знаний о процессоре или операционной системе, на которых он работает.
Совместимость Windows NT с NetWare
Существующая версия Windows NT 3.51 имеет встроенную поддержку стека протоколов Novell, а именно протоколов IPX/SPX и клиентской части NCP. При разработке первой версии Windows NT 3.1 между Microsoft и Novell существовало соглашение о том, что редиректор, реализующий клиентскую часть протокола NCP, будет написан силами сотрудников Novell и передан Microsoft в течение 60 дней после выпуска коммерческой версии Windows NT 3.1. Однако первая версия редиректора от Novell появилась только спустя четыре месяца и обладала существенными ограничениями: не поддерживался полностью API редиректора NetWare, в частности, поддерживались только 32-х разрядные вызовы, что означало невозможность работы старых 16 разрядных приложений клиента NetWare.
Через некоторое время Microsoft разработала свою собственную версию редиректора для NetWare, проведя большую работу по освоению NCP. Этот вариант оказался гораздо лучше, однако и он имеет недостатки: в нем отсутствует поддержка входных сценариев NetWare и службы каталогов NetWare Directory Services. Отсутствие поддержки входных сценариев означает, что администратору сети будет сложно автоматизировать создание индивидуальной операционной среды NetWare для пользователей, использующих Windows NT в качестве клиентской машины серверов NetWare.
Сеть с файловыми серверами различных типов (NetWare и Windows NT) порождает сложные технические проблемы. Даже если серверы используют одинаковые транспортные протоколы, в данном случае протокол IPX (в реализации Microsoft имеющий название NWLink), клиентским рабочим станциям все равно придется загружать два разных инициатора запросов. У клиента, работающего в среде MS-DOS, для этого может просто не хватить памяти.
Для смягчения перехода от NetWare к Windows NT Server разработано несколько инструментальных программ, в том числе утилита Migration Tool, которая включена в комплект поставки Windows NT Server. Эта утилита переносит учетную информацию пользователей (имена пользователей, ограничения и права доступа) и данные с одного или нескольких файловых серверов NetWare на сервер Windows NT. Migration Tool подбирает наилучшее соответствие между возможностями NetWare и возможностями Windows NT. Однако имеется ряд существенных различий в том, как обрабатываются такие вещи, как ограничения. В NetWare подобная информация обрабатывается для каждого пользователя в отдельности, а в Windows NT она общая для целого сервера.
Microsoft ведет работу над созданием своих собственных файл- и принт-серверов NetWare для Windows NT. Кроме этого, скоро должен появиться редиректор NetWare для Windows NT, поддерживающий NDS.
Рассмотренные способы организации взаимодействия сетей построены на использовании принципа мультиплексирования протоколов. Другим подходом является использование шлюза. Шлюз действует как транслятор, что позволяет получать доступ к файлам и ресурсам печати на файловом сервере NetWare, не пользуясь ничем, кроме загруженного редиректора Windows NT. Шлюз преобразовывает SMB-сообщения, посланные каким-либо Windows NT-клиентом, в NCP-сообщения, которые посылаются на серверы NetWare. В этом случае имеется экономия памяти на клиентских машинах, так как не требуется загружать дополнительные редиректоры.
Вариант шлюза подходит только для приложений, использующих для запросов к серверу NetWare только стандартный API, а при использовании специфического для NetWare API нельзя обойтись без установки дополнительного редиректора.
Если NetWare-шлюз загружен, Windows NT Server может подсоединиться к одному или нескольким файловым серверам NetWare и подключиться к любому дисковому тому, очереди на печать или каталогу. После того, как сервер подключился к ресурсам, их можно начинать использовать совместно с другими пользователями через File Manager или Print manager, как если бы они были локальными ресурсами. То есть пользователи, вошедшие в домен, на сервере которого установлен шлюз к NetWare, получают доступ к серверам NetWare.
Трансляция протоколов в шлюзе замедляет доступ к серверу NetWare по сравнению с доступом через редиректор клиента. При тестировании замедление в малозагруженном шлюзе составило от 10% до 15%.
Имя пользователя, используемое шлюзом для входа в сервер NetWare, должно входить в группу NTGateway на сервере Windows NT. Разрешение на доступ к ресурсам NetWare предоставляется пользователям сервером Windows NT точно так же, как если бы это были его локальные ресурсы.