28

Лекція 4 Реалізація архітектури операційної системи

Збільшення розміру і складності операційних систем призвело до виникнення трьох поширених проблем:

• операційні системи доходять до користувача з істотним запізненням,

• в системах присутні приховані помилки, що вимагають виправлення,

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

Шляхи вирішення цих проблем досить очевидні:

• система повинна складатися з модулів - це спрощує її написання і налагодження,

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

Незважаючи на очевидність таких рішень, виявилося, що для складних систем, які складаються з мільйонів і більше рядків, вони не позбавляють від всіх проблем.

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

Перелічимо основні типи внутрішньої архітектури операційних систем і розглянемо приклади архітектури найбільш поширених операційних систем - систем UNIX і Windows.

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

• мікроядерна архітектура,

• монолітна архітектура,

• багаторівнева архітектура,

• віртуальні машини,

• екзоядро,

• архітектура типу клієнт-сервер на базі мікроядра.

Розглянемо кожен з цих типів архітектури більш докладно.

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

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

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

Мікроядро працює з найвищим пріоритетом і забезпечує роботу решти операційної системи як набору серверних додатків. Технологія мікроядра Mach (МЕК) створена в університеті Карнегі Меллон і служить основою для багатьох операційних систем.

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

• управління віртуальною пам'яттю,

• управління завданнями і потоками,

• міжпроцесної комунікації (IPC - inter-process communication),

• керування вводом-висновком і переривань,

• забезпечення клієнт-серверного сервісу.

Тому до складу мікроядра входять:

• машинно-залежні модулі;

• модулі, що виконують основні базові функції ядра з управління процесами;

• обробка переривань;

• управління віртуальною пам'яттю;

• пересилання повідомлень і керування вводом-висновком

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

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

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

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

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

Рис 4.1 Перенесення основного обсягу функцій ядра в простір користувача

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

Переваги мікроядерної архітектури :

• висока переносимість;

• можливість розширення;

• висока надійність;

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

Недоліки мікроядерної архітектури

Більш низька продуктивність. Це позначається на швидкості роботи прикладних середовищ, а значить і на швидкості виконання додатків.

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

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

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

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

Мікроядерну концепцію використовують такі ОС, як Windows NT і деякі версії ОС UNIX.

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

ОС, в яких всі базові функції сконцентровані в ядрі, називаються монолітними.

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

Рис. 4.2. Монолітна структура ОС

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

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

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

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

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

Вимоги до архітектури операційної системи

Архітектура операційної системи повинна забезпечувати розширюваність операційної системи, переносимість операційної системи і сумісність різних операційних систем.

Проблема розширюваності операційної системи

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

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

Дійсно, операційна система зазвичай живе досить довго, наприклад UNIX існує вже більше 40 років, Windows NT - більше 20 років. За час життя операційної системи неминуче з'являється нове периферійне устаткування, підтримка якого не закладалася в систему при її проектуванні. Проте, для успішного існування на ринку, операційна система повинна швидко реагувати на появу нового обладнання і забезпечувати його підтримку. Прикладом може служити поява і широке поширення накопичувачів на компакт-дисках або Flash-пам'яті.

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

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

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

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

Проблема переносимості операційної системи

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

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

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

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

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

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

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

Проблема сумісності операційної системи

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

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

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

Розрізняють сумісність на рівні вихідних кодів, і двійкову(бінарну) сумісність.

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

Не вдаючись в технічні подробиці, відзначимо, що користувачів в переважній більшості випадків цікавить двійкова (бінарна) сумісність, а не сумісність на рівні вихідних кодів.

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

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

Є дві операційних системи, система A і система B. Обидві операційних системи давно і успішно працюють на деякій апаратній платформі. Необхідно в систему A ввести виконавчу середу системи B, щоб прикладні програми системи B могли б виконуватися також і в системі A.

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