72. Тенденції в структурній побудові ос: монолітні системи, багаторівневі системи, модель клієнт-сервер та мікро ядра.

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

Монолітні системи

У загальному випадку "структура" монолітної системи є відсутністю структури (малюнок 4.1). ОС написана як набір процедур, кожна з яких може викликати інші, коли їй це потрібно. При використанні цієї техніки кожна процедура системи має добре певний інтерфейс в термінах параметрів і результатів, і кожна вольна викликати будь-яку іншу для виконання деякої потрібної для неї корисної роботи.

Мал. 4.1. Монолітна структура ОС

Для побудови монолітної системи необхідно скомпілювати всі окремі процедури, а потім зв'язати їх разом в єдиний об'єктний файл за допомогою компонувальника (прикладами можуть служити ранні версії ядра UNIX або Novell NetWare). Кожна процедура бачить будь-яку іншу процедуру ( на відміну від структури, що містить модулі, в якій велика частина інформації є локальною для модуля, і процедури модуля можна викликати тільки через спеціально певні точки входу).

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

1. Головна програма, яка викликає необхідні сервісні процедури.

2. Набір сервісних процедур, що реалізовують системні виклики.

3. Набір утиліт, обслуговуючих сервісні процедури.

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

Мал. 4.2. Проста структуризація монолітної ОС

Багаторівневі системи

Узагальненням попереднього підходу є організація ОС як ієрархії рівнів. Рівні утворюються групами функцій операційної системи - файлова система, управління процесами і пристроями і т.п. Кожен рівень може взаємодіяти тільки з своїм безпосереднім сусідом - выше- або нижележащим рівнем. Прикладні програми або модулі самої операційної системи передають запити вгору і вниз по цих рівнях.

Першою системою, побудованою таким чином була проста пакетна система THE, яку побудував Дейкстра і його студенти в 1968 році.

Система мала 6 рівнів. Рівень 0 займався розподілом часу процесора, перемикаючи процеси по перериванню або після закінчення часу. Рівень 1 управляв пам'яттю - розподіляв оперативну пам'ять і простір на магнітному барабані для тих частин процесів (сторінок), для яких не було місця в ОП, тобто шар 1 виконував функції віртуальної пам'яті. Шар 2 управляв зв'язком між консоллю оператора і процесами. За допомогою цього рівня кожен процес мав свою власну консоль оператора. Рівень 3 управляв пристроями введення-висновку і буферизував потоки інформації до них і від них. За допомогою рівня 3 кожен процес замість того, щоб працювати з конкретними пристроями, з їх різноманітними особливостями, звертався до абстрактних пристроїв введення-висновку, що володіють зручними для користувача характеристиками. На рівні 4 працювали призначені для користувача програми, яким не треба було піклуватися ні про процеси, ні про пам'ять, ні про консоль, ні про управління пристроями введення-висновку. Процес системного оператора розміщувався на рівні 5.

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

Подальше узагальнення багаторівневої концепції було зроблене в ОС MULTICS. У системі MULTICS кожен рівень (званий кільцем) є більш привілейованим, ніж вищерозміщений. Коли процедура верхнього рівня хоче викликати процедуру нижележащего, вона повинна виконати відповідний системний виклик, тобто команду TRAP (переривання), параметри якої ретельно перевіряються перед тим, як виконується виклик. Хоча ОС в MULTICS є частиною адресного простору кожного призначеного для користувача процесу, апаратура забезпечує захист даних на рівні сегментів пам'яті, вирішуючи, наприклад, доступ до одних сегментів тільки для запису, а до інших - для читання або виконання. Перевага підходу MULTICS полягає в тому, що він може бути розширений і на структуру призначених для користувача підсистем. Наприклад, професор може написати програму для тестування і оцінки студентських програм і запустити цю програму на рівні n, тоді як студентські програми працюватимуть на рівні n+1, так що вони не зможуть змінити свої оцінки. Багаторівневий підхід був також використаний при реалізації різних варіантів ОС UNIX. Хоча такий структурний підхід на практиці зазвичай працював непогано, сьогодні він все більше сприймається монолітним. У системах, що мають багаторівневу структуру було нелегко видалити один шар і замінити його іншим через множинність і розмитість інтерфейсів між шарами. Додавання нових функцій і зміна що існують вимагало хорошого знання операційної системи і маси часу. Коли стало ясно, що операційні системи живуть довго і повинні мати можливості розвитку і розширення, монолітний підхід став давати тріщину, і на зміну йому прийшла модель клієнт-сервер і тісно пов'язана з нею концепція мікроядра.

Модель клієнт-сервер і мікроядра

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

Мал. 4.3. Структура ОС клієнт-сервер

Стосовно структуризації ОС ідея полягає в розбитті її на декілька процесів - серверів, кожний з яких виконує окремий набір сервісних функцій - наприклад, управління пам'яттю, створення або планування процесів. Кожен сервер виконується в призначеному для користувача режимі. Клієнт, яким може бути або інший компонент ОС, або прикладна програма, запрошує сервіс, посилаючи повідомлення на сервер. Ядро ОС (зване тут мікроядром), працюючи в привілейованому режимі, доставляє повідомлення потрібного сервера, сервер виконує операцію, після чого ядро повертає результати клієнтові за допомогою іншого повідомлення (малюнок 4.3). Підхід з використанням мікроядра замінив вертикальний розподіл функцій операційної системи на горизонтальний. Компоненти, лежачі вище мікроядра, хоч і використовують повідомлення, що пересилаються через мікроядро, взаємодіють один з одним безпосередньо. Мікроядро грає роль регулювальника. Воно перевіряє повідомлення, пересилає їх між серверами і клієнтами, і надає доступ до апаратури. Дана теоретична модель є описом системи, що ідеалізується, клієнт-сервер, в якій ядро складається тільки із засобів передачі повідомлень. Насправді різні варіанти реалізації моделі клієнт-сервер в структурі ОС можуть істотно розрізнятися за об'ємом робіт, що виконуються в режимі ядра. На одному краю цього спектру знаходиться та, що розробляється фірмою IBM на основі мікроядра Mach операційна система Workplace OS, що дотримується чистої мікроядерної доктрини, що полягає в тому, що всі неістотні функції ОС повинні виконуватися не в режимі ядра, а в непривілейованому (призначеному для користувача) режимі. На іншому - Windows NT, у складі якої є виконуюча система (NT executive), що працює в режимі ядра і виконує функції забезпечення безпеки, введення-висновку та інші. Мікроядро реалізує життєво важливі функції, лежачі в основі операційної системи. Це базис для менш істотних системних служб і застосувань. Саме питання про те, які з системних функцій вважати неістотними, і, відповідно, не включати їх до складу ядра, є предметом суперечки серед прихильників ідеї мікроядра, що змагаються. У загальному випадку, підсистеми, що були традиційно невід'ємними частинами операційної системи, - файлові системи, управління вікнами і забезпечення безпеки - стають периферійними модулями, що взаємодіють з ядром і один з одним. Головний принцип розділення роботи між мікроядром і модулями, що оточують його, - включати в мікроядро тільки ті функції, яким абсолютно необхідно виконуватися в режимі супервізора і в привілейованому просторі. Під цим зазвичай подразумеваются машиннозалежні програми (включаючи підтримку декількох процесорів), деякі функції управління процесами, обробка переривань, підтримка пересилки повідомлень, деякі функції управління пристроями введення-висновку, пов'язані із завантаженням команд в регістри пристроїв. Ці функції операційної системи важко, якщо не неможливо, виконати програмам, що працюють в просторі користувача.

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

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

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

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

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

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

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

Високий ступінь переносимості обумовлений тим, що важ машинно-залежний код ізольований в мікроядрі, тому для перенесення системи на новий процесор потрібно менше змін і всі вони логічно згруповані разом.

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

Розширюваність також є однією з важливих вимог до сучасних операційних систем. Чи є операційна система маленькою, як DOS, або великою, як UNIX, для неї неминуче настане необхідність набути властивостей, не закладених в її конструкцію. Складність монолітних операційних систем, що збільшується, робила важким, якщо взагалі можливим, внесення змін в ОС з гарантією надійності її подальшої роботи. Обмежений набір чітко певних інтерфейсів мікроядра відкриває шлях до впорядкованого зростання і еволюції ОС.

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

Іноді є потреба і в скороченні можливостей ОС. На Windows NT або UNIX перейшло б більше число користувачів, якби для цих операційних систем не було потрібно 16 Мб оперативної пам'яті і 70 Мб і більш за простір на жорсткому диску. Мікроядро не обов'язково подразумевает невелику систему. Надбудовані служби, типа файлової системи і системи управління вікнами, додадуть до неї немало. Звичайно ж, не всім потрібна безпека класу C2 або розподілені обчислення. Якщо важливі, але призначені для певних споживачів властивості можна виключати з складу системи, то базовий продукт підійде ширшому кругу користувачів.

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

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

Комерційні версії мікроядер

Однією з перших представила поняття мікроядра фірма Next, яка використовувала в своїх комп'ютерах систему Mach, що пройшла великий шлях розвитку в університеті Карнеги-меллона за допомогою агентства Міністерства оборони США DARPA. Теоретично, її невелике привілейоване ядро, оточене службами призначеного для користувача режиму, повинне було забезпечити безпрецедентну гнучкість і модульну. Але на практиці ця перевага була дещо зменшено наявністю монолітного сервера операційної системи BSD 4.3, який виконувався в призначеному для користувача просторі над мікроядром Mach. Проте Mach дав Next можливість надати службу передачі повідомлень і об'єктно-орієнтовані засоби, які з'явилися перед кінцевими користувачами як елегантний інтерфейс користувача з графічною підтримкою конфігурації мережі, системного администрирования і розробки програмного забезпечення.

Потім прийшла Microsoft Windows NT, що рекламувала як ключових переваг застосування мікроядра не тільки модульну, але і переносимість. Конструкція NT дозволяє їй працювати на системах на основі процесорів Intel, MIPS і Alpha (і подальших), і підтримувати симетричну многопроцессорность. Через те, що NT повинна була виконувати програми, написані для DOS, Windows, OS/2 і що використовують угоди POSIX, Microsoft використовувала модульну, властиву мікроядерному підходу для того, щоб зробити структуру NT такою, що не повторює жодну з існуючих операційних систем. Натомість NT підтримує кожну надбудовану операційну систему у вигляді окремого модуля або підсистеми.

Сучасніша архітектура мікроядра була запропонована Novell, USL, Open Software Foundation, IBM, Apple і іншими. Одним з основних суперників NT на арені мікроядер є мікроядро Mach 3.0, яке і IBM і OSF узялися привести до комерційного вигляду. (Next як основа для NextStep поки використовує Mach 2.5, але при цьому уважно придивляється до Mach 3.0.). Основний суперник Mach - мікроядро Chorus 3.0 фірми Chorus Systems, вибраний USL за основу для своїх пропозицій. Це ж мікроядро використовуватиметься в SPRINGOS фірми Sun, об'єктно-орієнтованому наступнику Solaris.

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