...
Концепції Windows NT PDF Печать E-mail

Структура: NT executive і захищені підсистеми

При розробці структури Windows NT була значною мірою використана концепція мікроядра. Відповідно до цієї ідеї ОС розділена на декілька підсистем, кожна з яких виконує окремий набір сервісних функцій - наприклад, сервіс пам'яті, сервіс по створенню процесів, або сервіс по плануванню процесів. Кожен сервер виконується в призначеному для користувача режимі, виконуючи цикл перевірки запиту від клієнта на одну з його сервісних функцій. Клієнт, яким може бути або інша компонента ОС, або прикладна програма, просить сервіс, посилаючи повідомлення на сервер. Ядро ОС (чи мікроядро), працюючи в привілейованому режимі, доставляє повідомлення потрібному серверу, потім сервер виконує операцію, після цього ядро повертає результати клієнтові за допомогою іншого повідомлення.

Структурно Windows NT може бути представлена у вигляді двох частин: частина операційної системи, що працює в режимі користувача, і частина операційної системи, що працює в режимі ядра (малюнок 8.1).

Частина Windows NT, що працює в режимі ядра, називається executive - старанною частиною. Вона включає ряд компонент, які управляють віртуальною пам'яттю, об'єктами (ресурсами), введенням-висновком і файловою системою (включаючи мережеві драйвери), взаємодією процесів і частково системою безпеки. Ці компоненти взаємодіють між собою за допомогою міжмодульної зв'язки. Кожна компонента викликає інші за допомогою набору ретельно специфікованих внутрішніх процедур.

Другу частину Windows NT, що працює в режимі користувача, складають сервери - так звані захищені підсистеми. Сервери Windows NT називаються захищеними підсистемами, оскільки кожен з них виконується в окремому процесі, пам'ять якого відокремлена від інших процесів системою управління віртуальною пам'яттю NT executive. Оскільки підсистеми автоматично не можуть спільно використовувати пам'ять, вони спілкуються один з одним за допомогою посилки повідомлень. Повідомлення можуть передаватися як між клієнтом і сервером, так і між двома серверами. Усі повідомлення проходять через старанну частину Windows NT. Ядро Windows NT планує нитки захищених підсистем так само, як і нитки звичайних прикладних процесів.

Підтримку захищених підсистем забезпечує старанна частина - Windows NT executive, яка працює в просторі ядра і ніколи не скидається на диск. Її складеними частями являються:

Менеджер об'єктів. Створює, видаляє і управляє об'єктами NT executive - абстрактними типами даних, використовуваних для представлення ресурсів системи.
Монітор безпеки. Встановлює правила захисту на локальному комп'ютері. Охороняє ресурси операційної системи, виконує захист і реєстрацію виконуваних об'єктів.
Менеджер процесів. Створює і завершує, припиняє і поновлює процеси і нитки, а також зберігає про них інформацію.
Менеджер віртуальної пам'яті.
Підсистема введення-виводу. Включає наступні компоненти:

менеджер введення-виводу, що надає засоби введення-висновку, незалежні від пристроїв;
файлові системи - NT -драйверы, що виконують файл-ориентированные запити на уведення-виведення і що транслюють їх у виклики звичайних пристроїв;
мережевий редиректор і мережевий сервер - драйвери файлових систем, передавальні видалені запити на уведення-виведення на машини мережі і одержуючі запити від них;
драйвери пристроїв NT executive - низькорівневі драйвери, які безпосередньо управляють пристроєм;
менеджер кеша, що реалізовує кешування диска.

Сумлінна частина, у свою чергу, грунтується на службах нижнього рівня, що надаються ядром (його можна назвати і мікроядром) NT. У функції ядра входить:

планування процесів,
обробка переривань і виняткових ситуацій,
синхронізація процесорів для багатопроцесорних систем,
відновлення системи після збоїв.

Ядро працює в привілейованому режимі і ніколи не видаляється з пам'яті. Звернутися до ядра можна тільки за допомогою переривання. Ядро розташовано над рівнем апаратних абстракцій (Hardware Abstraction Level HAL), який концентрує в одному місці велику частину машинно-залежних процедур. HAL розташовується між NT executive і апаратним забезпеченням і приховує від системи такі деталі, як контроллери переривань, інтерфейси введення/виводу і механізми взаємодії між процесорами. Таке рішення дозволяє легко переносити Windows NT з однієї платформи на іншу шляхом заміни тільки шару HAL.

При створенні NT розробники керувалися завданнями поліпшення продуктивності і мережевих можливостей, а також вимогою підтримки певного набору прикладних середовищ. Ця мета була досягнута продуманим розподілом функцій між модулями ядра і іншими модулями. Наприклад, передача даних у файлову систему і по мережі робиться швидше в просторі ядра, тому усередині ядра NT виділені буфера для невеликих за об'ємом (від 16 до 32 Кб) операцій читання і запису, що є типовими для додатків клієнт-сервер і розподілених застосувань. Розміщення цих функцій введення-висновку усередині ядра, може, і псує академічну чистоту мікроядра NT, але відповідає меті створення NT.

Захищені підсистеми Windows NT працюють в призначеному для користувача режимі і створюються Windows NT в час завантаження операційною системи. Відразу після створення вони починають нескінченний цикл свого виконання, відповідаючи на повідомлення, що поступають до них від прикладних процесів і інших підсистем. Серед захищених підсистем можна виділити підклас, званий підсистемами оточення. Підсистеми оточення реалізують інтерфейси додатків операційної системи (API). Інші типи підсистем, звані інтегральними підсистемами, виконують необхідні операційній системі завдання. Наприклад, велика частина системи безпеки Windows NT реалізована у виді інтегральної підсистеми, мережеві сервери також виконані як інтегральні підсистеми.

Найбільш важливою підсистемою оточення являється Win32 - підсистема, яка забезпечує доступ для додатків до 32 - bit Windows API. Додатково ця система забезпечує графічний інтерфейс з користувачем і управляє введенням/виводом даних користувача. Також підтримуються підсистеми POSIX, OS/2,16-розрядна Windows і MS - DOS.

Кожна захищена підсистема працює в режимі користувача, викликаючи системний сервіс NT executive для виконання привілейованих дій в режимі ядра. Мережеві сервери можуть виконуватися як у режимі користувача, так і в режимі ядра, залежно від того, як вони розроблені.

Підсистеми зв'язуються між собою шляхом передачі повідомлень. Коли, наприклад, призначене для користувача застосування викликає яку-небудь API -процедуру, підсистема оточення, що забезпечує цю процедуру, отримує повідомлення і виконує її або звертаючись до ядру, або посилаючи повідомлення іншій підсистемі. Потім завершення процедури підсистема оточення посилає додатку повідомлення, повертане, що містить значення. Посилка повідомлень і інша діяльність захищених підсистем невидима для користувача.

Основним засобом, що скріплює усі підсистеми Windows NT в єдине ціле, являється механізм виклику локальних процедур (Local Procedure Call - LPC). LPC є оптимізований варіант загальнішого засобу - видаленого виклику процедур (RPC), яке використовується для зв'язку клієнтів і серверів, розташованих на різних машинах мережі.

Засоби LPC підтримують декілька способів передачі даних між клієнтами і серверами: один зазвичай використовується для передачі коротких повідомлень, інший - для довгих повідомлень, а третій оптимізований спеціально для використання підсистемою Win32. Кожна підсистема встановлює порт - канал зв'язки, за допомогою якого з їй можуть зв'язуватися інші процеси. Порти реалізуються як об'єкти.

Windows NT використовує захищені підсистеми для того, щоб:

Забезпечити декілька програмних інтерфейсів (API)по можливості не ускладнюючи при цьому базовий програмний код (NT executive).
Ізолювати базову операційну систему від змін або розширень в підтримуваних API.
Об'єднати частину глобальних даних, що вимагаються усім API, і в те ж час відокремити дані, що використовуються кожним окремим API від даних, що використовуються іншими API.
Захистити оточення кожного API від додатків, а також від оточень інших API, і захистити базову операційну систему від різних оточень.
Дозволити операційній системі розширюватися в майбутньому за рахунок нових API.

Таким чином, реалізація частин ОС у вигляді серверів, що виконуються в режимі користувача, являється найважливішою частиною проекту Windows NT і робить глибоке дія на усе функціонування системи.

Мікроядро NT служить, головним образом, засобом підтримки для переносимої основної частини ОС - набору призначених для користувача середовищ. Концентрація машинно-залежних програм усередині мікроядра робить перенесення NT на різноманітні процесори відносно легенею. Але в той час, як деякі мікроядра (Mach і Chorus) передбачається поставляти в якості самостійного програмного продукту, з операційної системи Windows NT ядро навряд чи може бути вичленувало для окремого використання. Це являється одній з причин того, що деякі фахівці не вважають Windows NT істинно мікроядерній ОС в тому сенсі, в якому такими є Mach і Chorus. Ті ж критики відмічають також, що NT не виключає, як це належить, усі надбудовані служби з простору ядра і що драйвери пристроїв в NT по мінімуму взаємодіють з ядром, вважаючи за краще працювати безпосередньо з тим, що лежить нижче шаром апаратної абстракції HAL.
Множинні прикладні середовища

При розробці 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 забезпечує підтримку дисплея, клавіатури і миші для чотирьох підсистем, що залишилися.

16-бітові додатки DOS і Windows працюють на VDM (virtual DOS machines - віртуальні машини DOS), кожна з яких емулює повний 80x86 процесор з MS - DOS. У NT VDM являється додатком Win32, значить, як і звичайні модулі прикладних середовищ для UNIX, додатки DOS і 16-бітовою Windows розташовані в шарі безпосередньо над підсистемою 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 і не являється повністю об'єктно-орієнтованою, в її основі лежать об'єкти. Однакова форма іменування, спільного використання і обліку системних ресурсів, простій і дешевий спосіб забезпечення безпеці системи і її модифікації - усі ці переваги можуть бути досягнуті при використанні об'єктній моделі.

У Windows NT будь-який ресурс системи, який одночасно може бути використаний більш ніж одним процесом, включаючи файли, спільно використовувану пам'ять і фізичні пристрої, реалізований у вигляді об'єкту і управляється рядом функцій. Такий підхід скорочує число змін, які необхідно внести в операційну систему в процесі її експлуатації. Якщо, скажімо, змінилося щось у апаратурі, то усе, що необхідно зробити - замінити відповідний об'єкт. Аналогічно, якщо вимагається підтримка нових ресурсів, то потрібно додати тільки новий об'єкт, не змінюючи при цьому іншого коду операційної системи.

Найбільш фундаментальне відмінність між об'єктом і звичайною структурою даних полягає в тому, що внутрішня структура даних об'єкту прихована від спостереження. Ви повинні викликати об'єктну функцію для того, щоб отримати дані з об'єкту або помістити дані в об'єкт. Ви не можете безпосередньо змінювати дані, що знаходяться усередині об'єкту. Це відділяє засоби реалізації об'єкту від коду, який тільки використовує його, така техніка дозволяє легко змінювати в наслідку реалізацію об'єктів.

Група розробників NT executive вирішила використовувати об'єкти для представлення системних ресурсів, тому що об'єкти забезпечують централізовані засоби для виконання трьох важливих ( і часто стомливих) завдань ОС :

Підтримка сприйманих людиною імен системних ресурсів;
Розподіл ресурсів і даних між процесами;
Захист ресурсів від несанкціонованого доступу.

Не усі структури даних в NT executive є об'єктами. Об'єктами зроблені тільки такі дані, які треба розділяти, захищати, іменувати чи робити видимими для програм призначеного для користувача режиму ( за допомогою системних функцій). Структури, які використовуються тільки одним компонентом executive для виконання внутрішніх функцій, не є об'єктами.

Незважаючи на усебічне використання об'єктів для представлення тих, що розділяються ресурсів, Windows NT не являється об'єктно-орієнтованою системою в строгому сенсі. Велика частина коду операційної системи написана на Із з метою забезпечення переносимості. Незважаючи на те, що З не підтримує безпосередньо объектно-ориенти-
рованные конструкції, такі як динамічне зв'язування типів даних, поліморфні функції або спадкоємство класів, ці інструментальні засоби були використані із-за їх широкої поширеності.

Менеджер об'єктів - це компонента NT executive, яка відповідальна за створення, видалення, захист і стеження за NT -объектами. Менеджер об'єктів централізує операції управління ресурсами, які інакше будуть розкидані по усій ОС.

Менеджер об'єктів NT виконує наступні функції:

Виділяє пам'ять для об'єкту.
Приєднує до об'єкту так званий дескриптор безпеці, який визначає, кому дозволено використовувати об'єкт, і що вони можуть з ним робити.
Створює і маніпулює структурою каталогу об'єктів, в якому зберігаються імена об'єктів.
Створює описувач об'єкту і повертає його зухвалому процесу.

Процеси призначеного для користувача режиму, включаючи підсистеми оточення, повинні мати описувач об'єкту перед тим, як їх нитки зможуть використовувати цей об'єкт. Використання описувачів для роботи з системними ресурсами не є новою ідеєю. Наприклад, бібліотеки З і Паскаля (а також інших мов) повертають описувачі для відкритих файлів. Аналогічно додатки Win32 використовують різні типи описувачів для управління вікнами, курсором миші, іконками. У обох випадках описувачі служать непрямими покажчиками на системні ресурси; ця побічність оберігає прикладні програми від рутинної роботи безпосередньо з системними структурами даних.

Кожен NT -объект являється об'єктом певного типу. Тип визначає дані, які зберігає об'єкт, і "рідні" системні функції, які можуть до нього застосовуватися. Для того, щоб управляти різними об'єктами однаково, менеджер об'єктів вимагає, щоб кожен об'єкт містив декілька полів стандартної інформації в певному місці об'єкту. До тих пір, поки ці дані є, менеджер об'єктів не піклується про те, що ще зберігається в об'єкті. Кожен об'єкт складається з двох частин - заголовка об'єкту і тіла об'єкту, які містять стандартні і змінні дані об'єкту відповідно. Менеджер об'єктів працює із заголовком об'єкту, а інші компоненти executive працюють з тілами об'єктів тих типів, які вони самі створюють. Заголовок об'єкту використовується менеджером без обліку типу об'єкту. У заголовку об'єкту будь-якого типу міститься ім'я, каталог, дескриптор безпеці, квоти на використання ресурсів, лічильник відкритих описувачів, база даних відкритих описувачі, ознаку постійний/тимчасовий, режим користувача/ядра, покажчик на тип об'єкту.

Окрім заголовка об'єкту, кожен об'єкт має тіло об'єкту, формат і зміст якого унікально визначається типом цього об'єкту; у усіх об'єктів одного і того ж типу однаковий формат тіла. При створенні об'єкту старанна частина може оперувати даними в тілах усіх об'єктів цього типу.
Процеси і нитки

У різних ОС процеси реалізуються по-різному. Ці відмінності полягають в тому, якими структурами даних представлені процеси, як вони іменуються, якими способами захищені один від одного і які стосунки існують між ними. Процеси Windows NT мають наступні характерні властивості:

Процеси Windows NT реалізовані у формі об'єктів, і доступ до них здійснюється за допомогою служби об'єктів.
Процес Windows NT має багатонитяну організацію.
Як об'єкти-процеси, так і об'єкти-нитки мають вбудовані засоби синхронізації.
Менеджер процесів Windows NT не підтримує між процесами стосунків типу "батько-нащадок".

У будь-якій системі поняття "процес" включає наступне:

виконуваний код,
власне адресне простір, який є сукупність віртуальних адрес, які може використовувати процес,
ресурси системи, такі як файли, семафори і тому подібне, які призначені процесу операційної системою.
хоч би одну виконувану нитка.

Адресний простір кожного процесу захищено від втручання в нього будь-кого іншого процесу. Це забезпечується механізмами віртуальній пам'яті. Операційна система, звичайно, теж захищена від прикладних процесів. Щоб виконати яку-небудь процедуру ОС або прочитати що-небудь з її області пам'яті, нитка повинна виконуватися в режимі ядра. Призначені для користувача процеси дістають доступ до функцій ядра за допомогою системних викликів. У призначеному для користувача режимі виконуються не лише прикладні програми, але і захищені підсистеми Windows NT.

У Windows NT процес - це просто об'єкт, що створюється і знищуваний менеджером об'єктів. Об'єкт-процес, як і інші об'єкти, містить заголовок, який створює і ініціалізував менеджер об'єктів. Менеджер процесів визначає атрибути, що зберігаються у тілі об'єкту-процесу, а також забезпечує системний сервіс, який відновлює і змінює ці атрибути.

У число атрибутів тіла об'єкту-процесу входять:

Ідентифікатор процесу - унікальне значення, яке ідентифікує процес у рамках операційної системи.
Токен доступу - виконуваний об'єкт, що містить інформацію про безпеці.
Базовий пріоритет - основа для сумлінного пріоритету ниток процесу.
Процесорна сумісність - набір процесорів, на яких можуть виконуватися нитки процесу.
Граничні значення квот - максимальна кількість сторінковою і несторінковою системній пам'яті, дискового простору, призначеного для вивантаження сторінок, процесорного часу - які можуть бути використані процесами користувача.
Час виконання - загальний кількість часу, в течія якого виконуються усі нитки процесу.

Нагадаємо, що нитка являється виконуваною одиницею, яка розташовується в адресному просторі процесу і використовує ресурси, виділені процесу. Подібно до процесу нитка в Windows NT реалізована у формі об'єкту і управляється менеджером об'єктів.

Об'єкт-нитка має наступні атрибути тіла :

Ідентифікатор клієнта - унікальне значення, яке ідентифікує нитка при її зверненні до серверу.
Контекст нитки - інформація, яка потрібна ОС для того, щоб продовжити виконання перерваної нитки. Контекст нитки містить поточне стан регістрів, стеків і індивідуальною області пам'яті, яка використовується підсистемами і бібліотеками.
Динамічний пріоритет - значення пріоритету нитки в цей момент.
Базовий пріоритет - нижній межа динамічного пріоритету нитки.
Процесорна сумісність ниток - перелік типів процесорів, на яких може виконуватися нитка.
Час виконання нитки - сумарний час виконання нитки в призначеному для користувача режимі і у режимі ядра, накопичене за період існування нитки.
Стан попередження - прапор, який показує, що нитка повинна виконувати виклик асинхронної процедури.
Лічильник призупинень - поточна кількість призупинень виконання нитки.

Окрім перерахованих, є і деякі інші атрибути.

Як видно з переліку, багато атрибути об'єкту-нитки аналогічні атрибутам об'єкту-процесу. Дуже схожі і сервісні функції, які можуть бути виконані над об'єктами-процесами і об'єктами-нитками: створення, відкриття, завершення, призупинення, запит і установка інформації, запит і установка контексту і інші функції.
Алгоритм планування процесів і ниток

У Windows NT реалізована витісняюча багатозадачність, при якій операційна система не чекає, коли нитка сама захоче звільнити процесор, а примусово знімає її з виконання потім того, як та витратила відведений нею час (квант), або якщо в черзі готових з'явилася нитка з вищим пріоритетом. При такій організації розподілу процесора жодна нитка не займе процесор на дуже довгий час.

Мал. 8.3. Граф станів нитки

У ОС Windows NT нитка в ході свого існування може мати одне з шести станів (малюнок 8.3). Життєвий цикл нитки починається у той момент, коли програма створює нову нитку. Запит передається NT executive, менеджер процесів виділяє пам'ять для об'єкту-нитки і звертається до ядру, щоб ініціалізувати об'єкт-нитка ядра. Потім ініціалізації нитка проходить через наступні стани:

Готовність. При пошуку нитки на виконання диспетчер переглядає тільки нитки, що знаходяться в стані готовності, у яких є усе для виконання, але не хапає тільки процесора.
Першочергова готовність (standby). Для кожного процесора системи вибирається одна нитка, яка буде виконуватися наступною (найперша нитка в черги). Коли умови дозволяють, відбувається перемикання на контекст цій нитці.
Виконання. Як тільки відбувається перемикання контекстів, нитка переходить у стан виконання і знаходиться в нім доти, поки або ядро не витіснить її через те, що з'явилася більше пріоритетна нитка або закінчився квант часу, виділений цій нитці, або нитка завершиться взагалі, або вона по власній ініціативі перейде в стан очікування.
Очікування. Нитка може входити в стан очікування декількома способами: нитка по своїй ініціативі чекає деякий об'єкт для того, щоб синхронізувати своє виконання; операційна система (наприклад, підсистема введення-висновку) може чекати в інтересах нитки; підсистема оточення може безпосередньо змусити нитку припинити себе. Коли очікування нитки підійде до кінцю, вона повертається в стан готовності.
Перехідний стан. Нитка входить в перехідне стан, якщо вона готова до виконання, але ресурси, які їй потрібні, зайняті. Наприклад, сторінка, що містить стек нитки, може бути вивантажена з оперативній пам'яті на диск. При звільненні ресурсів нитка переходить в стан готовності.
Завершення. Коли виконання нитки закінчилося, вона входить в стан завершення. Знаходячись в цьому стані, нитка може бути або видалена, або не видалена. Це залежить від алгоритму роботи менеджера об'єктів, відповідно до якого він і вирішує, коли видаляти об'єкт. Якщо executive має покажчик на об'єкт-нитку, те вона може бути ініціалізувала і використана знову.

Диспетчер ядра використовує для визначення порядку виконання ниток алгоритм, заснований на пріоритетах, у відповідності з яким кожній нитці привласнюється число - пріоритет, і нитки з більше високим пріоритетом виконуються раніше ниток з меншим пріоритетом. У самому початку нитка отримує пріоритет від процесу, який створює її. У свою чергу, процес отримує пріоритет в того момент, коли його створює підсистема тій або іншій прикладного середовища. Значення базового пріоритету привласнюється процесу системою за умовчанням або системним адміністратором. Нитка наслідує цей базовий пріоритет і може змінити його, трохи збільшивши або зменшивши. На підставі того, що вийшов в результаті пріоритету, званого пріоритетом планування, починається виконання нитки. У ході виконання пріоритет планування може мінятися.

Windows NT підтримує 32 рівні пріоритетів, розділених на два класи - клас реального часу і клас змінних пріоритетів. Нитки реального часу, пріоритети яких знаходяться в діапазоні від 16 до 31, є пріоритетнішими процесами і використовуються для виконання завдань, критичних до часу.

Кожного разу, коли необхідно вибрати нитку для виконання, диспетчер передусім переглядає чергу готових ниток реального часу і звертається до інших ниток, тільки коли черга ниток реального часу порожня. Більшість ниток в системі потрапляють в клас ниток із змінними пріоритетами, діапазон пріоритетів яких від 0 до 15. Цей клас має назва "Змінні пріоритети" тому, що диспетчер настроює систему, вибираючи (знижуючи або підвищуючи) пріоритети ниток цього класу.

Алгоритм планування ниток у Windows NT об'єднує в собі обоє базових концепції - квантування і пріоритети. Як і у усіх інших алгоритмах, заснованих на квантуванні, кожній нитці призначається квант, впродовж якого вона може виконуватися. Нитка звільняє процесор, якщо:

блокується, йдучи в стан очікування;
завершується;
вичерпаний квант;
у черзі готових з'являється більше пріоритетна нитка.

Використання динамічних пріоритетівщо змінюються в часу, дозволяє реалізувати адаптивне планування, при якому не дискримінуються інтерактивні завдання, часто виконуючі операції введення-висновку і недоиспользующие виділені ним кванти. Якщо нитка повністю вичерпала свій квант, то її пріоритет знижується на деяку величину. У те ж час пріоритет ниток, які перейшли в стан очікування, не використавши повністю виділений ним квант, підвищується. Пріоритет не змінюється, якщо нитка витиснена пріоритетнішою ниткою.

Для того, щоб забезпечити хороший час реакції системи, алгоритм планування використовує разом з квантуванням концепцію абсолютних пріоритетів. У відповідності з цією концепцією при появі в черзі готових ниток такій, у якої пріоритет вищий, ніж у що виконується в даний момент, відбувається зміна активної нитки на нитку з найвищим пріоритетом.

У багатопроцесорних системах при диспетчеризації і плануванні ниток грає роль їх процесорна сумісність: після того, як ядро вибрало нитка з найвищим пріоритетом, воно перевіряє, який процесор може виконати цю нитку і, якщо атрибут нитки "процесорна сумісність" не дозволяє нитці виконуватися ні на одному з вільних процесорів, то вибирається наступна в порядку пріоритетів нитка.
Мережеві засоби

Засобу мережевого взаємодії Windows NT спрямовані на реалізацію взаємодії з існуючими типами мереж, забезпечення можливості завантаження і вивантаження мережевого програмного забезпечення, а також на підтримку розподілених застосувань.

Windows NT з точки зору реалізації мережевих засобів має наступні особливості:

Встроенность на рівні драйверів. Ця властивість забезпечує швидкодія.
Відкритість - обумовлюється легкістю динамічною завантаження-вивантаження, мультиплексируемостью протоколів.
Наявність RPC, що іменуються конвеєрів і поштових ящиків для підтримки розподілених застосувань .
Наявність додаткових мережевих засобів, що дозволяють будувати мережі масштабах корпорації : додаткові кошти безпеці централізоване адміністрування відмовостійкість (UPS, дзеркальні диски).

Windows NT успадкувала від своїх попередників редиректор і сервер, протокол верхнього рівня SMB і транспортний протокол NetBIOS (правда, з новим "наповненням" - NetBEUI). Як і у мережі MS - NET редиректор перенаправляє локальні запити введення-виводу на видалений сервер, а сервер приймає і обробляє ці запити.

Спочатку редиректор і сервер були написані на асемблері і розташовувалися над існуючим системним програмним забезпеченням 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 являється протоколом прикладного рівня, що включає мережевий рівень і рівень представлення.

SMB реалізує:

встановлення сесії,
файловий сервіс,
сервіс друку,
сервіс повідомлень.

Інтерфейс, відповідно до яким редиректор посилає блоки SMB, називається інтерфейсом транспортних драйверів (transport driver interface - TDI). Редиректор викликає функції TDI для передачі блоків SMB різним транспортним драйверам, завантаженим в Windows NT. Для виклику функцій TDI редиректор повинен відкрити канал, званий віртуальним зв'язком (virtual circuit), до машині призначення, а потім послати SMB -сообщение через цю віртуальний зв'язок. Редиректор створює тільки одну віртуальний зв'язок для кожного сервера, з яким сполучена система Windows NT, і мультиплексирует через неї запити до цього сервера. Транспортний рівень визначає, яким чином реалізувати віртуальний зв'язок, і пересилає дані через мережу.

Як і редиректор, сервер Windows NT на 100% поєднаємо з існуючими SMB -протоколами MS - NET і LAN Manager. Ця повна сумісність дозволяє серверу обробляти запити, витікаючі не лише від систем Windows NT, але і від інших систем, що працюють з програмним забезпеченням LAN Manager. Як і редиректор, сервер виконаний у виді драйвера файлової системи.

Може здатися дивним, що сервер відповідно до мікроядерною концепцією не реалізований як серверний процес. Було б логічне чекати, що мережевий сервер функціонуватиме як захищена підсистема - процес, чиї нитки чекають вступи запитів по мережі, виконують їх, а потім повертають результати по мережі. Цей підхід, як найбільш природний, був ретельно розглянутий при проектуванні Windows NT, проте, враховуючи досвід побудови мереж VAX/VMS і досвід використання RPC, було вирішено виконати сервер як драйвер файлової системи. Хоча сервер і не є драйвером в звичайному сенсі, і він не управляє файловою системою на самій справі, використання моделі драйвера забезпечує деякі переваги.

Головне з них полягає в тому, що драйвер реалізований в середовищі NT executive і може викликати кеш-менеджер NT безпосередньо, що оптимізує передачу даних. Наприклад, коли сервер отримує запит на читання великої кількості даних, він викликає кеш-менеджер для визначення місця розташування цих даних в кеші (чи для завантаження цих даних в кеш, якщо їх там немає) і для фіксації даних в пам'яті. Потім сервер передає дані безпосередньо з кеша в мережу, минувши доступ до диска. Аналогічно, при запиті на запис даних сервер викликає кеш-менеджер для резервування місця для даних, що поступають. Потім сервер пише дані безпосередньо у кеш. Записуючи дані в кеш, сервер повертає управління клієнтові набагато швидше; потім кеш-менеджер записує дані на диск у фоновому режимі (використовуючи сторінкові засоби менеджера віртуальної пам'яті).

Будучи драйвером файлової системи, сервер декілька гнучкіший в порівнянні з його реалізацією у вигляді процесу. Наприклад, він може реєструвати функції завершення введення-виводу, що дозволяє йому отримувати управління негайно потім завершення роботи драйверів нижнього рівня. Хоча сервер Windows NT реалізований як драйвер файлової системи, інші сервери можуть бути реалізовані і як драйвери, і як серверні процеси.

Асинхронні виклики обробляються сервером аналогічно, з використанням пулу робочих ниток.

І редиректоры, і сервери, і транспортні драйвери можуть бути в будь-який час завантажені і вивантажені.

Відкрита архітектура мережевих засобів Windows NT забезпечує роботу своїх робочих станцій (і серверів) в гетерогенних мережах не лише шляхом надання можливості динамічно завантажувати і вивантажувати мережеві засоби, але і шляхом безпосереднього перемикання з програмних мережевих засобів, орієнтованих на взаємодія з одним типом мереж, на програмні засоби для іншого типу мереж в ході роботи системи. Windows NT підтримує перемикання програмних засобів на трьох рівнях:

на рівні редиректоров - кожен редиректор призначений для свого протоколу (SMP, NCP, NFS, VINES);
на рівні драйверів транспортних протоколів, надаючи для них і для редиректоров стандартний інтерфейс TDI;
на рівні драйверів мережевих адаптерів - із стандартним інтерфейсом NDIS 3.0.

Для доступу до інших типів мереж в Windows NT, окрім вбудованого, можуть завантажуватися додаткові редиректоры. Спеціальні компоненти Windows NT вирішують, який редиректор має бути викликаний для обслуговування запиту на видалене уведення-виведення. За останні десятиліття набули поширення різні протоколи передачі інформації по мережі. І хоча Windows NT підтримує не усі ці протоколи, вона, принаймні, дозволяє включати їх підтримку.

Після того, як мережевий запит досягає редиректора, він має бути переданий в мережу. У традиційній системі кожен редиректор жорстко пов'язаний з певним транспортним протоколом. У Windows NT поставлена завдання гнучкого підключення того або іншого транспортного протоколу, залежно від типу транспорту, використовуваного у іншій мережі. Для цього в усіх редиректорах нижній рівень має бути написаний у відповідності з визначеними угодами, які і визначають єдиний програмний інтерфейс, званий інтерфейсом транспортних драйверів (TDI).

TDI дозволяє редиректорам залишатися незалежним від транспорту. Таким чином, одна версія редиректора може користуватися будь-яким транспортним механізмом. TDI забезпечує набір функцій, які редиректоры можуть використовувати для пересилки будь-яких типів даних з допомогою транспортного рівня. TDI підтримує як зв'язки зі встановленням з'єднання (віртуальні зв'язки)так і зв'язки без встановлення з'єднання (датаграмні зв'язки). Хоча LAN Manager використовує зв'язки зі встановленням з'єднань, Novell IPX є прикладом мережі, яка використовує зв'язок без встановлення з'єднання. Microsoft спочатку забезпечує транспорт - NetBEUI (NetBIOS Extended User Interface), TCP/IP, IPX/SPX, DECnet і AppleTalk.

Мережеві адаптери поставляються разом з мережевими драйверами, які раніше часто були розраховані на взаємодія з визначеним типом транспортного протоколу. Оскільки Windows NT дозволяє завантажувати драйвери різних транспортних протоколів, то виробники мережевих адаптерів, що використовують такій підхід, повинні були писати різні варіанти одного і того ж драйвера, розраховані на зв'язок з різними протоколами транспортного рівня.

Щоб допомогти виробникам уникнути цього, Windows NT забезпечує інтерфейс і програмне середовище, звані "специфікація інтерфейсу мережевого драйвера" (NDIS), які екранують мережеві драйвери від деталей різних транспортних протоколів. Самий верхній рівень драйвера мережевого адаптера має бути написаний відповідно до рекомендаціями NDIS. У цьому випадку користувач може працювати з мережею TCP/IP і мережею NetBEUI (чи DECnet, NetWare, VINES і тому подібне), використовуючи один мережевий адаптер і один мережевий драйвер. Середовище NDIS використовувалася в мережах LAN Manager, але для Windows NT вона була оновлена.

Через свій нижній кордон драйвер мережевого адаптера зазвичай взаємодіє безпосередньо з адаптером чи адаптерами, які він обслуговує. Драйвер мережевого адаптера, реалізований для середовища NDIS, управляє адаптером не безпосередньо, а використовує для цього функції, NDIS (наприклад, для запуску введення-виводу або обробки переривань), що надаються. Таким образом, середовище NDIS утворює деяку оболонку, яка дозволяє досить просто переносити драйвери мережевих адаптерів з однієї ОС в іншу. NDIS дозволяє мережевим драйверам не містити вбудованих знань про процесор або операційну системі, на яких він працює.
Сумісність Windows NT з NetWare

Сумісність мережевих операційних систем припускає використання однакового стека комунікаційних протоколів, в тому числі і верхньому прикладного рівня. Протоколи верхнього рівня включають дві частини - клієнтську і серверну. При взаємодії двох комп'ютерів на кожній стороні можуть бути присутніми як обоє частини прикладного протоколу, так і по одній його частині, в залежності від цього утворюється або одна, або дві пари "клієнт-сервер".

Для клієнтської частини протоколу верхнього рівня, реалізованого у вигляді модуля операційної системи, використовуються різні назви - редиректор (redirector), ініціатор запитів або запросчик (requester). Ці компоненти отримують запити від додатків на доступ до видалених ресурсів, розташованим на серверах, і ведуть діалог з сервером у відповідності з яким-небудь протоколом прикладного рівня. Сукупність функцій, яка може використовувати додаток для звернення до редиректору, називається прикладним інтерфейсом (API) редиректора.

Існуюча версія 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 якості:

клієнтською робочою станції,
файлового сервера або сервера друку разом з NetWare,
файлового сервера або сервера друку замість 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 вона загальна для цілого сервера.

Компанія Beame and Whiteside Software створила перший NFS сервер для Windows NT, а також продукт під назвою BW - Multiconnect, який перетворює сервер Windows NT на сервер NetWare. Системи Windows NT зі встановленим продуктом BW - Multiconnect посилають широкомовні повідомлення по протоколу SAP (протокол оголошення сервісів і серверів по мережі - Service Advertising Protocol, з допомогою якого клієнти NetWare дізнаються про наявність в мережі серверів і про ті послуги, які вони надають). BW - Multiconnect повинен полегшити співіснування і міграцію від NetWare до Windows NT. Хоча він і може працювати як єдиний NCP -сервер мережі, він не призначений для цієї ролі, так як надає лише обмежений набір утиліт під Windows і DOS, і не обробляє вхідних командних файлів NetWare. Але коли в мережі є "справжній" файловий сервер NetWare, то користувачі можуть увійти до цього сервера, виконати системний вхідний командний файл, а потім під'єднатися до сервера Windows NT. Цей продукт перетворює на сервер NetWare як Windows NT Server, так і Windows NT Workstation.

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 точно так, як і якби це були його локальні ресурси.

 

Яндекс.Метрика >