Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
РЕФЕРАТ
З предмету Операційні системи
План
1. Основні принципи побудови ОС
2. Особливості методів побудови
3. Особливості областей використання
3.1 Вимоги до ОС реального часу.
3.2 Мультипрограмність і багатозадачність.
3.3 Пріоритети задач (потоків).
3.4 Присвоєння пріоритету та синхронізація процесів і задач.
3.5 Передбачливість.
4. Мікроядерні ОС
4.1. Мікроядерна архітектура
4.2. Переваги і недоліки мікроядерної архітектури
4.3 Ядро і допоміжні модулі ОС
4.4 Багатошарова структура ОС
5. Монолітні операційні системи.
6. Висновок.
1. Основні принципи побудови ОС
Серед безлічі принципів, що використовуються при побудові ОС, перечислимо найбільш важливі:
Принцип модульності
Під модулем у загальному випадку розуміють функціонально закінчений елемент системи, виконаний відповідно до прийнятого міжмодульними інтерфейсами. По своєму визначенню модуль припускає можливість без зусиль замінити його на інший при наявності заданих інтерфейсів. Способи відокремлення складових частин ОС в окремі модулі можуть істотно розрізнятися, але найчастіше поділ відбувається саме по функціональній ознаці. У значній мірі поділ системи на модулі визначається використовуваним методом проектування ОС (знизу чи нагору навпаки).
Принцип модульності відбиває технологічні й експлуатаційні властивості системи. Найбільший ефект від його використання досяжний у випадку, коли принцип розповсюджений одночасно на ОС, ПП й апаратуру.
Принцип функціональної вибірковості
В ОС виділяється деяка частина важливих модулів, що повинні постійно знаходитися в ОП для більш ефективної організації обчислюючого процесу. Цю частину в ОС називають ядром, тому що це дійсно основа системи. При формуванні складу ядра потрібно враховувати дві суперечливих вимоги. До складу ядра повинні ввійти найбільше часто використовувані системні модулі. Кількість модулів повинна бути таким, щоб обсяг пам'яті, займаний ядром, був би не занадто великим. До складу ядра, як правило, входять модулі по керуванню системою переривань, засоби по перекладу програм зі стану рахунку в стан чекання, готовності і зворотньо, засобу по розподілі таких основних ресурсів, як ОП і процесор. Крім програмних модулів, що входять до складу ядра і постійно розташовуються в ОП, може бути багато інших системних програмних модулів, що одержують назву транзитних. Транзитні програмні модулі завантажуються в ОП тільки при необхідності й у випадку відсутності вільного простору можуть бути заміщені іншими транзитними модулями.
Принцип генерування ОС
Основне положення цього принципу визначає такий спосіб вихідного представлення центральної системної керуючої програми ОС (її ядра й основних компонентів, що повинні постійно знаходитися в ОП), що дозволяв би набудовувати цю системну супервізорну частину, виходячи з конкретної конфігурації конкретного обчислювального комплексу і кола розв'язуваних задач. Ця процедура проводиться рідко, перед досить протяжним періодом експлуатації ОС. Процес генерації здійснюється за допомогою спеціальною програми-генератора і відповідної вхідної мови для цієї програми, що дозволяє описувати програмні можливості системи і конфігурацію машини. У результаті генерації виходить повна версія ОС. Генеруюча версія ОС являє собою сукупність системних наборів модулів і даних.
У наші дні при використанні персональних комп'ютерів із принципом генерування ОС можна зіштовхнутися хіба що тільки при роботі з Linux. У цієї UNIX системи мають можливість не тільки використовувати яке-небудь готове ядро ОС, але і самому згенерувати (скомпілювати) таке ядро, що буде оптимальним для даного конкретного ПК і розв'язуваних на ньому задач.
Принцип функціональної надмірності
Цей принцип враховує можливість проведення однієї і тієї ж роботи особистими засобами. До складу ОС може входити кілька типів моніторів (модулів супервізора, керуючих тим чи іншим видом ресурсу), різні засоби організації комунікацій між обчислювальними процесами. Наявність декількох типів моніторів, декількох систем керування файлами дозволяє користувачам швидко і найбільше адекватно адаптувати ОС до визначеної конфігурації обчислювальної системи, забезпечити максимально еф ективно завантаження технічних засобів при рішенні конкретного класу за дач, одержати максимальну продуктивність при рішенні заданого класу задач.
Принцип віртуалізації
Побудова віртуальних ресурсів, їхній розподіл і використання тепер використовується практично в будь-який ОС. Цей принцип дозволяє представити структуру системи у виді визначеного набору планувальників процесів і розподільників ресурсів (моніторів) і використовувати єдину централізовану схему розподілу ресурсів.
Найбільш природним і закінченим проявом концепції віртуальності є поняття віртуальної машини(ВМ). По суті, будь-яка ОС, будучи засобом розподілу ресурсів і організувати за визначеними правилами керування процесами, ховає від користувача і його додатків реальні апаратні й інші ресурси, заміняючи їх деякою абстракцією. У результаті користувачі бачать і використовують ВМ як деякий пристрій, здатний сприймати їхні програми, написані визначеною мовою програмування і видавати результати. При такому мовному представленні користувача зовсім не цікавить реальна конфігурація обчислювальної системи, способи ефективного використання її компонентів і підсистем. Він мислить і працює з машиною в термінах використовуваного ним мови і тих ресурсів, що йому надаються в рамках віртуальної машини.
Частіше ВМ, надана користувачу, відтворює архітектуру реальної машини, але архітектурні елементи в такому представленні виступають з новими чи поліпшеними характеристиками, що часто спрощують роботу із системою. Характеристики можуть бути довільними, але найчастіше користувачі бажають мати власну «ідеальну» по архітектурних характеристиках машину в наступному складі:
à однакову по логіці роботи пам'ять (віртуальна) практично необмеженого обсягу. Середній час доступу порівняний зі значенням цього параметра ОП. Організація роботи з інформацією в такій пам'яті виробляється в термінах обробки даних — у термінах роботи із сегментами даних на рівні обраної користувачем мови програмування;
à довільну кількість процесорів (віртуальних), здатних працювати паралельно і взаємодіяти під час роботи. Способи керування процесорами, у тому числі синхронізація й інформаційні взаємодії, реалізовані і доступні користувачам на рівні використовуваної мови в термінах керування процесами;
à довільна кількість зовнішніх пристроїв (віртуальних), здатних працювати з пам'яттю ВМ паралельно чи послідовно, асинхронно чи синхронно стосовно роботи того чи іншого віртуального процесора, що ініціюють роботу цих пристроїв. Інформація, передана чи збережена на віртуальних пристроях, не обмежена припустимими розмірами. Доступ до такої інформації здійснюється на основі або послідовного, або прямого способу доступу в термінах відповідної системи керування файлами. Передбачено розширення інформаційних структур даних, збережених на віртуальних пристроях.
Ступінь наближення до «ідеального» в ВМ може бути більший чи менший у кожному конкретному випадку. Чим більше ВМ, реалізована засобами ОС на базі конкретної апаратури, наближена до «ідеального» по характеристиках машини і, отже, чим більше її архітектурно-логічні характеристики відмінні від реально існуючих, тим більше ступінь віртуальності в отриманої користувачем машини.
Одним з аспектів віртуалізації є організація можливості виконання в даної ОС додатків, що розроблялися для інших ОС. Другими словами, мова йде про організацію декількох операційних середовищ. Реалізація цього принципу дозволяє такій ОС мати дуже сильну перевагу перед аналогічними ОС, що не мають такої можливості. Прикладом реалізації принципу віртуалізації може служити VDM-машина (Virtual DOS machine) — захищена підсистема, що надає повне середовище MS-DOS і консоль для виконання VS-DOS додатків. Одне тимчасово може виконуватися практично довільне число VDM-сесій. Такі VDM-машини маються й у системах Microsoft Windows та в OS/2.
Принцип незалежності програм від зовнішніх пристроїв
Цей принцип реалізується зараз у переважній більшості ОС загального призначення. Ми вже говорили про нього, розглядаючи принципи організації в/в. Мабуть, вперше найбільш послідовно даний принцип був реалізований в ОС UNIХ. Реалізований він і в більшості сучасних ОС для ПК. Нагадаємо, цей принцип полягає в тому, що зв'язок програм з конкретними пристроями виробляється не на рівні трансляції програми, а в період планування її виконання. У результаті перекомпіляція при роботі програми з новим пристроєм, на якому розташовуються дані, не потрібно.
Принцип дозволяє однаково здійснювати операції керування зовнішніми пристроями незалежно від їхніх конкретних фізичних характеристик. Наприклад, програми, що містять операції обробки послідовного набору даних, байдуже, на якому носії ці дані будуть розташовуватися. Зміна носія і даних, розташовуваних на них (при незмінності структурних характеристик даних), не принесе яких-небудь змін у програму, якщо в системі реалізований принцип незалежності.
Принцип сумісності
Одним з аспектів сумісності є здатність ОС виконувати програми, написані для інших ОС чи для більш ранніх версій даної ОС, а також для іншої апаратної платформи.
Необхідно розділяти питання двійкової сумісності і сумісності на рівні вихідних текстів додатків. Двійкова сумісність досягається в тому випадку, коли можна взяти програму, що виконується, і запустити її на виконання на інший ОС. Для цього необхідні: сумісність на рівні команд процесора, сумісність на рівні системних викликів і навіть на рівні бібліотечних викликів, якщо вони є зв’язуваними.
Сумісність на рівні вихідних текстів вимагає наявності відповідного транслятора в складі системного ПЗ, а також сумісності на рівні бібліотек і системних викликів. При цьому необхідна перекомпіляція наявних вихідних текстів у новий виконуваний модуль.
Одним із засобів забезпечення сумісності програмних і користувацьких інтерфейсів є відповідність стандартам РОSIX. Використання стандарту РОSIХ дозволяє створювати програми в стилі UNIX, що згодом можуть легко переноситися з однієї системи в іншу.
Принцип відкритої і нарощуваної ОС
Відкрита ОС доступна для аналізу як користувачам, так і системним фахівцям, що обслуговують обчислювальну систему. Нарощувана (що модифікується, що розвивається) ОС дозволяє не тільки використовувати можливості генерації, але і вводити в її склад нові модулі, удосконалювати існуючі і т.д. Іншими словами, необхідно, щоб можна було легко внести доповнення і зміни, якщо це буде потрібно, і не порушити цілісність системи. Прекрасні можливості для розширення надає підхід до структурування ОС по типі клієнт-сервер з використанням мікроядерної технології. Відповідно до цього підходу ОС будується як сукупність привілейованої керуючої програми і набору непривілейованих послуг — «серверів». Основна частина ОС залишається незмінною й у той же час можуть бути додані нові чи сервери поліпшені старі.
Цей принцип іноді трактують як розширюваність системи. До відкритих ОС, насамперед, варто віднести UNIX - системи і, природно, ОС Linux.
Принцип мобільності (переносимості)
ОС відносно легко повинна переноситися з процесора одного типу на процесор іншого типу і з апаратної платформи (яка включає поряд з типом процесора і спосіб організації всієї апаратури комп'ютера, інакше кажучи, архітектуру обчислювальної системи) одного типу на апаратну платформу іншого типу. Помітимо, що принцип переносимості дуже близький принципу сумісності, хоча це і не те саме.
Написання стерпної ОС аналогічне написанню будь-якого стерпного коду — потрібно випливати деяким правилам. По-перше, велика частина ОС повинна бути написана мовою, що є на всіх системах, на яких планується надалі її переносити. Це, насамперед, означає, що ОС повинна бути написана мовою високого рівня, переважно стандартизованому, наприклад мовою С. Програма, написана на асемблері, не є в загальному випадку стерпною. По-друге, важливо чи мінімізувати, якщо можливо, виключити ті частини коду, що безпосередньо взаємодіють з апаратними засобами. Залежність від апаратури може мати багато форм. Деякі очевидні форми залежності включають пряме маніпулювання регістрами й іншими апаратними засобами. Нарешті, якщо апаратно-залежний код не може бути цілком виключений, то він повинний бути ізольований у декількох добре локальних модулях. Апаратно-залежний код не повинен бути розподілений по всій системі. Наприклад, можна сховати апаратно-залежну структуру в дані абстрактного типу, що задаються програмно. Інші модулі системи будуть працювати з цими даними, а не з апаратурою, використовуючи набір деяких функцій. Коли ОС переноситься, то змінюються тільки ці дані і функції, що ними маніпулюють.
Уведення стандартів РОSIХ мало на меті забезпечити переносимість створюваного ПЗ.
Принцип забезпечення безпеки обчислень
Забезпечення безпеки при виконанні обчислень є бажаною властивістю для будь-якої багатокористувацької системи. Правила безпеки визначають такі властивості, як захист ресурсів одного користувача від інших і встановлення квот по ресурсах для запобігання захоплення одним користувачем усіх системних ресурсів (таких, як пам'ять).
Забезпечення захисту інформації від несанкціонованого доступу є обов'язковою функцією мережевих ОС. У багатьох сучасних ОС гарантується ступінь безпеки даних, що відповідає рівню С2 у системі стандартів США. Основи стандартів в області безпеки були закладені в документі «Критерії оцінки надійних комп'ютерних систем». Цей документ, виданий Національним центром комп'ютерної безпеки (NCSC — National Computer Security Centre) у США в 1983 році, часто називають Жовтогарячою книгою.
Відповідно до вимог Жовтогарячої книги безпечною вважається система, що «за допомогою спеціальних механізмів захисту контролює доступ до інформації таким чином, що тільки мають відповідні повноваження чи обличчя процеси, що виконуються від їхнього імені, можуть одержати доступ на читання, запис, чи створення видалення інформації».
Ієрархія рівнів безпеки, приведена в Жовтогарячій книзі, позначає нижчий рівень безпеки як D, а вищий — як А.
У клас D попадають системи, оцінка яких виявила їхню невідповідність вимогам всіх інших класів.
Основними властивостями, характерними для систем класу C, є наявність підсистеми обліку подій, зв'язаних з безпекою, і виборчий контроль доступу. Клас (рівень) C поділяється на 2 підрівня: рівень С1, що забезпечує захист даних від помилок користувачів, але не від дій зловмисників; і більш строгий рівень С2. На рівні С2 повинні бути присутніми:
à засоби секретного входу, що забезпечують ідентифікацію користувачів шляхом введення унікального імені і пароля перед тим, як їм буде дозволений доступ до системи;
à виборчий контроль доступу, що дозволяє власнику ресурсу визначити, хто має доступ до ресурсу і що він може з ним робити. Власник робить це шляхом наданих прав доступу чи користувачу групі користувачів;
à засоби обліку і спостереження (auditing) що забезпечують можливість знайти і зафіксувати важливі події, зв'язані з безпекою, чи будь-які спроби створити, одержати доступ чи видалити системні ресурси;
à захист пам'яті, що полягає в тім, що пам'ять ініціюється перед тим, як повторно використовується.
На цьому рівні система не захищена від помилок користувача, але поводження його може бути проконтрольоване по записах у журналі, залишеним засобами спостереження й аудита.
Системи рівня В засновані на позначених даних і розподілі користувачів по категоріях, тобто реалізують мандатний контроль доступу. Кожному користувачу привласнюється рейтинг захисту, і він може одержувати доступ до даних тільки відповідно до цього рейтингу. Цей рівень на відміну від рівня С захищає систему від помилкового поводження користувача.
Рівень А є найвищим рівнем безпеки, він вимагає на додаток до усіх вимог рівня B виконання формального, математично обґрунтованого доказу відповідності системи вимогам безпеки. Різні комерційні структури (наприклад, банки) особливо виділяють необхідність облікової служби, аналогічної тієї, що пропонують державні рекомендації С2. Будь-яка діяльність, зв'язана з безпекою, може бути відсліджена і тим самим врахована. Це саме те, чого вимагає стандарт для систем класу С2, і що звичайно потрібно банкам. Однак комерційні користувачі, як правило, не хочуть розплачуватися продуктивністю за підвищений рівень безпеки. А-рівень безпеки займає своїми керуючими механізмами до 90 % процесорного часу, що, безумовно, у більшості випадків уже неприйнятно. Більш безпечні системи не тільки знижують ефективність, але й істотно обмежують число доступних прикладних пакетів, що відповідним чином можуть виконуватися в подібній системі. Наприклад, для ОС Solaris (версія UNIX) є кілька тисяч додатків, а для її аналога В рівня — тільки біля ста.
2. Особливості методів побудови
При описі ОС часто вказуються особливості її структурної організації й основні концепції, покладені в її основу.
До таких базових концепцій відносяться:
- способи побудови ядра системи - монолітне чи ядро мікроядерний підхід. Більшість ОС використовує монолітне ядро, що компонується як одна програма, що працює в привілейованому режимі і використовує швидкий перехід з однієї процедури на іншу, не потребуючі переключення з привілейованого режиму в користувальницький і навпаки. Альтернативою є побудова ОС на базі мікроядра, що працює також у привілейованому режимі і виконуючого тільки мінімум функцій по керуванню апаратурою, у той час як функції ОС більш високого рівня виконують спеціалізовані компоненти ОС - сервери, що працюють у користувальницькому режимі. При такій побудові ОС працює більш повільно, тому що часто виконуються переходи між привілейованим режимом і користувацьким, зате система виходить більш гнучкої - її функції можна нарощувати, чи модифікувати звужувати, додаючи, чи модифікуючи крім серверів користувацького режиму. Крім того, сервери добре захищені один від одного, як і будь-які користувацькі процеси.
- Побудова ОС на базі об’єктно-орієнтованого підходу дає можливість використовувати всі його достоїнства, що добре зарекомендували себе на рівні додатків, всередині ОС, а саме: акумуляцію вдалих рішень у формі стандартних об'єктів, можливість створення нових об'єктів на базі наявних за допомогою механізму спадкування, гарний захист даних за рахунок їхньої інкапсуляції у внутрішні структури об'єкта, що робить дані недоступними для несанкціонованого використання ззовні, структуризованность системи, що складає з набору добре визначених об'єктів.
- Наявність декількох прикладних середовищ дає можливість у рамках однієї ОС одночасно виконувати додатка, розроблені для декількох ОС. Багато сучасних ОС підтримують одночасно прикладні середовища MS-DOS, Wіndows, UNІ (POSІ), OS/2 чи хоча б деякої підмножини з цього популярного набору. Концепція множинних прикладних середовищ найбільше просто реалізується в ОС на базі мікроядра, над яким працюють різні сервери, частина яких реалізують прикладне середовище тієї чи іншої ОС.
- Розподілена організація ОС дозволяє спростити роботу користувачів і програмістів у мережних середовищах. У розподіленої ОС реалізовані механізми, що дають можливість користувачу представляти і сприймати мережу у виді традиційного однопроцесорного комп'ютера. Характерними ознаками розподіленої організації ОС є: наявність єдиної довідкової служби розподілених ресурсів, єдиної служби часу, використання механізму виклику вилучених процедур (RPC) для прозорого розподілу програмних процедур по машинах, многонитевой обробки, що дозволяє розпаралелювати обчислення в рамках однієї задачі і виконувати цю задачу одночасно на декількох комп'ютерах мережі, а також наявність інших розподілених служб.
3. Особливості областей використання
Багатозадачні ОС підрозділяються на три типи відповідно до використаного при їхній розробці критерія ефективності:
· системи пакетної обробки (наприклад, OC EC),
· системи поділу часу (UNІ, VMS),
· системи реального часу (QNX, RT/11).
Системи пакетної обробки призначалися для розв’язання задач в основному обчислювального характеру, не потребуючого швидкого одержання результатів. Головною метою і критерієм ефективності систем пакетної обробки є максимальна пропускна здатність, тобто рішення максимального числа задач в одиницю часу. Для досягнення цієї мети в системах пакетної обробки використовуються наступна схема функціонування: на початку роботи формується пакет завдань, кожне завдання містить вимоги до системних ресурсів; з цього пакета завдань формується мультипрограмна суміш, тобто безліч одночасно виконуваних задач. Для одночасного виконання вибираються задачі, що пред'являють вимоги, що відрізняються, до ресурсів, так, щоб забезпечувалося збалансоване завантаження всіх будов обчислювальної машини; так, наприклад, у мультипрограмній суміші бажано одночасна присутність обчислювальних задач і задач з інтенсивним в/в. Таким чином, вибір нового завдання з пакета завдань залежить від внутрішньої ситуації, що складається в системі, тобто вибирається "вигідне" завдання. Отже, у таких ОС неможливо гарантувати виконання того чи іншого завдання протягом визначеного періоду часу. У системах пакетної обробки переключення процесора з виконання однієї задачі на виконання іншої відбувається тільки у випадку, якщо активна задача сама відмовляється від процесора, наприклад, через необхідність виконати операцію в/в. Тому одна задача може надовго зайняти процесор, що унеможливлює виконання інтерактивних задач. Таким чином, взаємодія користувача з обчислювальною машиною, на якій установлена система пакетної обробки, зводиться до того, що він приносить завдання, віддає його диспетчеру-оператору, а наприкінці дня після виконання всього пакета завдань одержує результат. Очевидно, що такий порядок знижує ефективність роботи користувача.
Системи поділу часу покликані виправити основний недолік систем пакетної обробки - ізоляцію користувача-програміста від процесу виконання його задач. Кожному користувачу системи поділу часу надається термінал, з якого він може вести діалог зі своєю програмою. Тому що в системах поділу часу кожній задачі виділяється тільки квант процесорного часу, жодна задача не займає процесор надовго, і час відповіді виявляється прийнятним. Якщо квант обраний досить невеликим, то у всіх користувачів, що одночасно працюють на одній і тій же машині, складається враження, що кожний з них одноосібно використовує машину. Ясно, що системи поділу часу володіють меншою пропускною здатністю, ніж системи пакетної обробки, тому що на виконання приймається кожна запущена користувачем задача, а не та, котра "вигідна" системі, і, крім того, маються накладні витрати обчислювальної потужності на більш часте переключення процесора з задачі на задачу. Критерієм ефективності систем поділу часу є не максимальна пропускна здатність, а зручність і ефективність роботи користувача.
Системи реального часу застосовуються для керування різними технічними об'єктами, такими, наприклад, як верстат, супутник, наукова експериментальна чи установка технологічними процесами, такими, як гальванічна лінія, доменний процес і т.п. У всіх цих випадках існує гранично припустимий час, протягом якого повинна бути виконана та чи інша програма, що керує об'єктом, у іншому випадку може відбутися аварія: супутник вийде з зони видимості, експериментальні дані, що надходять з датчиків, будуть загублені, товщина гальванічного покриття не буде відповідати нормі. Таким чином, критерієм ефективності для систем реального часу є їхня здатність витримувати заздалегідь задані інтервали часу між запуском програми й одержанням результату (керуючого впливу). Цей час називається часом реакції системи, а відповідне властивість системи - реактивністю. Для цих систем мультипрограмна суміш являє собою фіксований набір заздалегідь розроблених програм, а вибір програми на виконання здійснюється виходячи з поточного стану чи об'єкта відповідно до розкладу планових робіт.
Деякі ОС можуть сполучати в собі властивості систем різних типів, наприклад, частина задач може виконуватися в режимі пакетної обробки, а частина - у режимі реального часу чи в режимі поділу часу. У таких випадках режим пакетної обробки часто називають фоновим режимом.
3.1. Вимоги до ОС реального часу.
Як відомо система реального часу має давати відклик на будь-який не передбачуваний зовнішній вплив за певний час. Для цього вона повинна мати наступні властивості:
- обмежений час відгуку;
- одночасна обробка даних.
Основні вимоги до ОС реального часу:
3.2 Мультипрограмність і багатозадачність.
ОС повинна бути мультипрограмною і багатозадачною і активно використовувати переривання для диспетчеризації.
3.3 Пріоритети задач (потоків).
В ОС повинно існувати поняття пріоритету потока.
3.4 Присвоєння пріоритету та синхронізація процесів і задач.
В ОС повинна існувати система присвоєння пріоритетів. ОС повинна забезпечити сильний, надійний і зручний механізми синхронізації задач.
3.5. Передбачливість.
Поведінка ОС повинна бути відомою і досить точно прогнозованою.
4. Мікроядерні ОС
4.1. Мікроядерна архітектура
Суть мікроядерної архітектури полягає в наступному. У привілейованому режимі залишається працювати тільки дуже невелика частина ОС, називана мікроядром (мал. 39). Мікроядро захищене від інших частин ОС і додатків. До складу мікроядра звичайно входять машинно-залежні модулі, а також модулі, що виконують базові (але не всі) функції ядра по керуванню процесами, обробці переривань, керуванню ВП, пересиланню повідомлень і керуванню пристроями в/в, зв'язані з завантаженням чи читанням регістрів пристроїв. Набір функцій мікроядра звичайно відповідає функціям шару базових механізмів звичайного ядра.
Утиліти ОС
Програми Утиліти ОС Програми
користувача користувачів
Сервери ОС
Режим користувача Режим користувача
Режим привілеєвій Режим привілеєвій
а б
Рис. 39
Переніс основного обсягу функцій ядра в користувацький простір
Всі інші більш високорівневі функції ядра оформляються у вигляді додатків, що працюють у користувацькому режимі. Однозначного рішення про те, які із системних функцій потрібно залишити в привілейованому режимі, а які перенести в користувацький, не існує. У загальному випадку багато менеджерів ресурсів, що є невід'ємними частинами звичайного ядра — ФС, підсистеми керування ВП і процесами, менеджер безпеки і т.п., — стають «периферійними» модулями, що працюють у користувацькому режимі.
Працюючі в користувацькому режимі менеджери ресурсів мають принципові відмінності від традиційних утиліт і обробних програм ОС, хоча при мікроядерній архітектурі всі ці програмні компоненти також оформлені у виді додатків. Утиліти й обробні програми викликаються в основному користувачами. Ситуації, коли одному додатку потрібно виконання функції (процедури) іншого додатка, виникають украй рідко. Тому в ОС із класичною архітектурою відсутній механізм, за допомогою якого один додаток міг би викликати функції іншого.
Зовсім інша ситуація виникає, коли у формі додатка оформляється частина ОС. По визначенню, основним призначенням такого додатка є обслуговування запитів інших додатків, наприклад створення процесу, виділення пам'яті, перевірка прав доступу до ресурсу і т.д. Саме тому менеджери ресурсів, внесені в користувацький режим, називаються серверами ОС, тобто модулями, основним призначенням яких є обслуговування запитів локальних додатків і інших модулів ОС. Очевидно, що для реалізації мікроядерної архітектури необхідною умовою є наявність в ОС зручного й ефективного способу виклику процедур одного процесу з іншого. Підтримка такого механізму і є однієї з головних задач мікроядра.
Схематично механізм звертання до функцій ОС, оформленим у виді серверів, виглядає в такий спосіб (мал. 40). Клієнт, яким може бути або ПП, або інший компонент ОС, запитує виконання деякої функції у відповідного сервера, посилаючи йому повідомлення. Безпосередня передача повідомлень між додатками неможлива, тому що їхні адресні простори ізольовані один від одного. Мікроядро, що виконується в привілейованому режимі, має доступ до адресних просторів кожного з цих додатків і тому може працювати як посередник. Мікроядро спочатку передає повідомлення, що містить ім'я і параметри викликаючої процедури потрібному серверу, потім сервер виконує запитану операцію, після чого ядро повертає результати клієнту за допомогою іншого повідомлення. Таким чином, робота мікроядерної ОС відповідає відомої моделі клієнт-сервер, у якій роль транспортних засобів виконує мікроядро.
Програми користувачів
Зв’язана Зв’язаний запит
відповідь
Режим користувача
Режим привілеїв
Рис. 40.Реалізація системного виклику в мікроядерній архітектурі
4.2. Переваги і недоліки мікроядерної архітектури
ОС, засновані на концепції мікроядра, у високому ступені задовольняють більшості вимог, пропонованих до сучасних ОС, володіючи переносимістю, розширюваністю, надійністю і створюючи гарні передумови для підтримки розподілених додатків. За ці переваги приходиться платити зниженням продуктивності, і це є основним недоліком мікроядерної архітектури.
Високий ступінь переносимості обумовлений тим, що весь машинно-залежний код ізольований у мікроядрі, тому для переносу системи на новий процесор потрібно менше змін і усі вони логічно згруповані разом.
Розширюваність присутня в мікроядерній ОС у дуже високому ступені. У традиційних системах навіть при наявності багатошарової структури нелегко видалити один шар і поміняти його на іншій через множинність і розмитість інтерфейсів між шарами. Додавання нових функцій і зміна існуючих вимагає гарного знання ОС і великих витрат часу. У той же час обмежений набір чітко визначених інтерфейсів мікроядра відкриває шлях до упорядкованого росту й еволюції ОС. Додавання нової підсистеми вимагає розробки нового додатка, що ніяк не торкає цілісності мікроядра. Мікроядерна структура дозволяє не тільки додавати, але і скорочувати число компонентів ОС, що також буває дуже корисно. Наприклад, не всім користувачам потрібні засоби безпеки чи підтримки розподілених обчислень, а видалення їх із традиційного ядра найчастіше неможливо. Звичайно традиційні ОС дозволяють динамічно додавати в ядро чи видаляти з ядра тільки драйвери зовнішніх пристроїв — через часті зміни в конфігурації підключених до комп'ютера зовнішніх пристроїв підсистема в/в ядра допускає завантаження і вивантаження драйверів «на ходу», але для цього вона розробляється особливим чином (наприклад, середовище STREAMS у UNIX чи менеджер в/в в Windows NT). При мікроядерному підході конфігурованість ОС не викликає ніяких проблем і не вимагає особливих мір — досить змінити файл із настроюваннями початкової конфігурації системи чи ж зупинити не потрібні більше сервери в ході роботи звичайними для зупинки додатків засобами.
Використання мікроядерної моделі підвищує надійність ОС. Кожен сервер виконується у виді окремого процесу у своїй власній області пам'яті й у такий спосіб захищений від інших серверів ОС, що не спостерігається в традиційної ОС, де всі модулі ядра можуть впливати один на одного. І якщо окремий сервер терпить крах, то він може бути перезапущений без зупинки чи ушкодження інших серверів ОС. Більш того, оскільки сервери виконуються в користувацькому режимі, вони не мають безпосереднього доступу до апаратури і не можуть модифікувати пам'ять, у якій зберігається і працює мікроядро. Іншим потенційним джерелом підвищення надійності ОС є зменшений обсяг коду мікроядра в порівнянні з традиційним ядром — це знижує імовірність появи помилок програмування.
Модель з мікроядром добре підходить для підтримки розподілених обчислень, тому що використовує механізми, аналогічні мережним: взаємодія клієнтів і серверів шляхом обміну повідомленнями. Сервери мікроядерної ОС можуть працювати як на одному, так і на різних комп'ютерах. У цьому випадку при одержанні повідомлення від додатка мікроядро може обробити його самостійно і передати локальному серверу чи ж переслати по мережі мікроядру, що працює на іншому комп'ютері. Перехід до розподіленої обробки вимагає мінімальних змін у роботі ОС — просто локальний транспорт заміняється на мережний.
Продуктивність. При класичній організації ОС (мал.41, а) виконання системного виклику супроводжується двома переключеннями режимів, а при мікроядерній організації (мал. 40, 6) — чотирьма. Таким чином, ОС на основі мікроядра за інших рівних умов завжди буде менш продуктивною, чим ОС із класичним ядром. Саме з цієї причини мікроядерний підхід не одержав такого широкого поширення, що йому пророкували.
Програми Програми
Ядро
а
Програми t t Сервер ОС Програми
Мікро ядро Мікроядро
б t t t t
Рис. 40. Зміна режимів при виконанні системного виклику
Серйозність цього недоліку добре ілюструє історія розвитку Windows NT. У версіях 3.1 і 3.5 диспетчер вікон, графічна бібліотека і високорівневі драйвери графічних пристроїв входили до складу сервера користувацького режиму, і виклик функцій цих модулів здійснювався відповідно до мікроядерної схеми. Однак дуже незабаром розроблювачі Windows NT зрозуміли, що такий механізм звертань до часто використовуваних функцій графічного інтерфейсу істотно сповільнює роботу додатків і робить дану ОС уразливої в умовах гострої конкуренції. У результаті у версію Windows NT 4.0 минулого внесені істотні зміни — усі перераховані вище модулі були перенесені в ядро, що віддалило цю ОС від ідеальної мікроядерної архітектури, але зате різко підвищило її продуктивність.
Цей приклад ілюструє головну проблему, з яким зіштовхуються розроблювачі ОС, що вирішили застосувати мікроядерний підхід, — що включати в мікроядро, а що виносити в користувацький простір. В ідеальному випадку мікроядро може складатися тільки з засобів передачі повідомлень, засобів взаємодії з апаратурою, у тому числі засобів доступу до механізмів привілейованого захисту. Однак багато розроблювачів не завжди жорстко дотримують принципу мінімізації функцій ядра, часто жертвуючи цим заради підвищення продуктивності. У результаті реалізації ОС утворять деякий спектр, на одному з краї якого знаходяться системи з мінімально можливим мікроядром, а на іншому — системи, подібні Windows NT, у яких мікроядро виконує досить великий обсяг функцій.
4.3. Ядро і допоміжні модулі ОС
Найбільш загальним підходом до структуризації ОС є поділ усіх її модулів на дві групи:
q ядро — модулі, що виконують основні функції ОС;
q модулі, що виконують допоміжні функції ОС.
Модулі ядра виконують такі базові функції ОС, як керування процесами, пам'яттю, пристроями в/в і т.п. Ядро складає серцевину ОС, без нього ОС є цілком непрацездатною і не зможе виконати ні одну зі своїх функцій.
До складу ядра входять функції, що вирішують внутрішньосистемні задачі організації обчислювального процесу, такі як переключення контекстів, завантаження/вивантаження, обробка переривань. Ці функції недоступні для додатків. Інший клас функцій ядра служить для підтримки додатків, створюючи для них так назване прикладне програмне середовище. Додатки можуть звертатися до ядра з запитами — системними викликами — для виконання тих чи інших дій, наприклад для відкриття і читання файлу, виведення графічної інформації на дисплей, одержання системного часу і т.д. Функції ядра, що можуть викликатися додатками, утворять інтерфейс прикладного програмування — API.
Функції, виконувані модулями ядра, є найбільше часто використовуваними функціями ОС, тому швидкість їхнього виконання визначає продуктивність усієї системи в цілому. Для забезпечення високої швидкості роботи ОС усі модулі чи ядра велика їхня частина постійно знаходяться в ОП, тобто є резидентними.
Ядро є рушійною силою всіх обчислювальних процесів у комп'ютерній системі, і крах ядра рівносильний краху всієї системи. Тому розроблювачі ОС приділяють особливу увагу надійності кодів ядра, у результаті процес їхнього налагодження може розтягуватися на багато місяців.
Оскільки деякі компоненти ОС оформлені як звичайні додатки, тобто у виді модулів, що виконуються, стандартного для даної ОС формату, те часто буває дуже складно провести чітку грань між ОС і додатками (мал. 41).
Рис. 41.Нечіткість границі між ОС і додатками
Допоміжні модулі ОС звичайно підрозділяються на наступні групи:
q утиліти — програми, що вирішують окремі задачі керування і супроводи комп'ютерної системи, такі, наприклад, як програми стиску дисків, архівування даних на магнітну стрічку;
q системні обробні програми — текстові чи графічні редактори, компілятори, компоновщики, відладчики;
q програми надання користувачу додаткових послуг — спеціальний варіант користувацького інтерфейсу, калькулятор і навіть гра;
q бібліотеки процедур різного призначення, що спрощують розробку додатків, наприклад бібліотека математичних функцій, функцій в/в і т.д.
Як і звичайні додатки, для виконання своїх задач утиліти, що обробляють програми і бібліотеки ОС, звертаються до функцій ядра за допомогою системних викликів (мал. 42).
Поділ ОС на ядро і модулі-додатки забезпечує легку розширюваність ОС. Щоб додати нову високорівневу функцію, досить розробити новий додаток, і при цьому не потрібно модифікувати відповідальні функції, що утворять ядро системи. Однак внесення змін у функції ядра може виявитися набагато складніше, і складність ця залежить від структурної організації самого ядра. У деяких випадках кожне виправлення ядра може зажадати його повної перекомпіляції.
Рис. 42.Взаємодія між ядром і
допоміжними модулями ОС
Модулі ОС, оформлені у виді утиліт, системних обробних програм і бібліотек, звичайно завантажуються в ОП тільки на час виконання своїх функцій, тобто є транзитними. Постійно в ОП розташовуються тільки найнеобхідніші коди ОС, що складають її ядро. Така організація ОС заощаджує ОП комп'ютера.
Важливою властивістю архітектури ОС, заснованої на ядрі, є можливість захисту кодів і даних ОС за рахунок виконання функцій ядра в привілейованому режимі.
4.4. Багатошарова структура ОС
Обчислювальну систему, що працює під керуванням ОС на основі ядра, можна розглядати як систему, що складається з трьох ієрархічно розташованих шарів: нижній шар утворить апаратура, проміжний — ядро, а утиліти, що обробляють програми і додатки, складають верхній шар системи (мал. 43). Шарувату структуру обчислювальної системи прийнято зображувати у виді системи концентричних окружностей, ілюструючи той факт, що кожен шар може взаємодіяти тільки із суміжними шарами. Дійсно, при такій організації ОС додатка не можуть безпосередньо взаємодіяти з апаратурою, а тільки через шар ядра.
Багатошаровий підхід є універсальним і ефективним способом декомпозиції складних систем будь-якого типу, у тому числі і програмних. Відповідно до цього підходу система складається з ієрархії шарів. Кожен шар обслуговує вищележачий шар, виконуючи для нього деякий набір функцій, що утворять міжшаровий інтерфейс (мал. 44). На основі функцій нижчележачого шару наступний (нагору по ієрархії) шар будує свої функції — більш складні і більш могутні, котрі, у свою чергу, виявляються примітивами для створення ще більш могутніх функцій вищележачого шару. Строгі правила стосуються тільки взаємодії між шарами системи, а між модулями усередині шару зв'язки можуть бути довільними. Окремий модуль може виконати свою роботу або самостійно, або звернутися до іншого модулю свого шару, або звернутися по допомогу до нижчележачого шару через міжшаровий інтерфейс.
Така організація системи має багато переваг. Вона істотно спрощує розробку системи, тому що дозволяє спочатку визначити «зверху вниз» функції шарів і міжшарові інтерфейси, а потім при детальній реалізації поступово нарощувати потужність функцій шарів, рухаючи «знизу нагору». Крім того, при модернізації системи можна змінювати модулі усередині шару без необхідності робити які-небудь зміни в інших шарах, якщо при цих внутрішніх змінах міжшарові інтерфейси залишаються в силі.
Рис. 44.Концепція багатошарової взаємодії
Оскільки ядро являє собою складний багатофункціональний комплекс, то багатошаровий підхід звичайно поширюється і на структуру ядра.
Ядро може складатися з наступних шарів.
q Засобу апаратної підтримки ОС. Дотепер про ОС говорилося як про комплекс програм, але, узагалі говорячи, частина функцій ОС може виконуватися й апаратними засобами. Тому іноді можна зустріти визначення ОС як сукупності програмних і апаратних засобів, що і відбито на мал. 45. До ОС відносять, природно, не всі апаратні пристрої комп'ютера, а тільки засоби апаратної підтримки ОС, тобто ті, котрі прямо беруть участь в організації обчислювальних процесів: засоби підтримки привілейованого режиму, систему переривань, засоби переключення контекстів процесів, засоби захисту областей пам'яті і т.п.
q Машинно-залежні компоненти ОС. Цей шар утворюють програмні модулі, у яких відбивається специфіка апаратної платформи комп'ютера. В ідеалі цей шар цілком екранує вищележачі шари ядра від особливостей апаратури. Це дозволяє розробляти вищележачі шари на основі машинно-незалежних модулів, що існують у єдиному екземплярі для всіх типів апаратних платформ, підтримуваних даною ОС. Прикладом шару, що екранує, може служити шар HAL ОС Windows NT.
q Базові механізми ядра. Цей шар виконує найбільш примітивні операції ядра, такі як програмне переключення контекстів процесів, диспетчеризацію переривань, переміщення сторінок з пам'яті на диск і назад і т.п. Модулі даного шару не приймають рішень про розподіл ресурсів — вони тільки відпрацьовують прийняті «нагорі» рішення, що і дає привід називати їх виконавчими механізмами для модулів верхніх шарів. Наприклад, рішення про те, що в даний момент потрібно перервати виконання поточного процесу А и почати виконання процесу В, приймається менеджером процесів на вищележачому шарі, а шару базових механізмів передається тільки директива про те, що потрібно виконати переключення з контексту поточного процесу на контекст процесу В.
q Менеджери ресурсів. Цей шар складається з могутніх функціональних модулів, що реалізують стратегічні задачі по керуванню основними ресурсами обчислювальної системи. Звичайно на даному шарі працюють менеджери (названі також диспетчерами) процесів, в/в, ФС й ОП. Розбивка на менеджери може бути і трохи іншим, наприклад менеджер ФС іноді поєднують з менеджером в/в, а функції керування доступом користувачів до системи в цілому і її окремих об'єктах доручають окремому менеджеру безпеки. Кожний з менеджерів веде облік вільних і використовуваних ресурсів визначеного типу і планує їхній розподіл відповідно до запитів додатків. Наприклад, менеджер ВП керує переміщенням сторінок з ОП на диск і назад. Менеджер повинний відслідковувати інтенсивність звертань до сторінок, час перебування їх у пам'яті, стани процесів, що використовують дані, і багато інших параметрів, на підставі яких він час від часу приймає рішення про те, які сторінки необхідно вивантажити і які — завантажити. Для виконання прийнятих рішень менеджер звертається до нижчележачого шару базових механізмів із запитами про завантаження (вивантаження) конкретних сторінок. Усередині шару менеджерів існують тісні взаємні зв'язки, що відбивають той факт, що для виконання процесу потрібний доступ одночасно до декількох ресурсів — процесору, області пам'яті, можливо, до визначеного файлу чи пристрою в/в. Наприклад, при створенні процесу менеджер процесів звертається до менеджера пам'яті, що повинний виділити процесу визначену область пам'яті для його кодів і даних.
q Інтерфейс системних викликів. Цей шар є самим верхнім шаром ядра і взаємодіє безпосередньо з додатками і системними утилітами, утворити прикладний програмний інтерфейс ОС. Функції API, що обслуговують системні виклики, надають доступ до ресурсів системи в зручній і компактній формі, без указівки деталей їхнього фізичного розташування. Наприклад, в ОС UNIX за допомогою системного виклику fd = open("/doc/a.txt", 0_RDONLY) додаток відкриває файл a.txt, що зберігається в каталозі /doc, а за допомогою системного виклику read(fd, buffer, count) читає з цього файлу в область свого адресного простору, що має ім'я buffer, деяку кількість байт. Для здійснення таких комплексних дій системні виклики звичайно звертаються по допомогу до функцій шару менеджерів ресурсів, причому для виконання одного системного виклику може знадобитися кілька таких звертань.
Рис. 45. Багатошарова структура ядра ОС
Приведена розбивка ядра ОС на шари є досить умовним. У реальній системі кількість шарів і розподіл функцій між ними може бути й іншим. У системах, призначених для апаратних платформ одного типу, наприклад ОС NetWare, шар машинно-залежних модулів звичайно не виділяється, зливаючи із шаром базових механізмів і, частково, із шаром менеджерів ресурсів. Не завжди оформляються в окремий шар базові механізми — у цьому випадку менеджери ресурсів не тільки планують використання ресурсів, але і самостійно реалізують свої плани.
Спосіб взаємодії шарів у реальної ОС також може відхилятися від описаної вище схеми. Для прискорення роботи ядра в деяких випадках відбувається безпосереднє звертання з верхнього шару до функцій нижніх шарів, минаючи проміжні. Типовим прикладом такої «неправильної» взаємодії є початкова стадія обробки системного виклику. На багатьох апаратних платформах для реалізації системного виклику використовується інструкція програмного переривання. Цим додаток фактично викликає модуль первинної обробки переривань, що знаходиться в шарі базових механізмів, а вже цей модуль викликає потрібну функцію із шару системних викликів. Самі функції системних викликів також іноді порушують субординацію ієрархічних шарів, звертаючи прямо до базових механізмів ядра.
Вибір кількості шарів ядра є відповідальною і складною справою: збільшення числа шарів веде до деякого уповільнення роботи ядра за рахунок додаткових накладних витрат на міжшарову взаємодію, а зменшення числа шарів погіршує розширюваність і логічність системи. Звичайно ОС, що пройшли довгий шлях еволюційного розвитку, наприклад багато версій UNIX, мають неупорядковане ядро з невеликим числом чітко виділених шарів, а в порівняно «молодих» ОС, таких як Windows NT, ядро розділене на більше число шарів і їхня взаємодія формалізована в набагато більшому ступені.
5. Монолітні операційні системи
Монолітні ОС є прямою протилежністю мікроядерним ОС. При цьому можна погодитися з тим, як трактується архітектура монолітних ОС. У монолітної ОС, незважаючи на її можливу сильну структуризацію, дуже важко видалити один з рівнів багаторівневої модульної структури. Додавання нових функцій і зміна існуючих для монолітних ОС вимагає дуже гарного знання всієї архітектури ОС і надзвичайно більших зусиль. Тому більше сучасний підхід до проектування ОС, що може бути умовно названий як «клієнт-серверна» технологія, дозволяє в більшій мері й з меншими трудозатратами: реалізувати перераховані вище принципи проектування ОС.
Модель клієнт-сервер припускає наявність програмного компонента, що є споживачем якого-небудь сервісу — клієнта, і програмного компонента, що служить постачальником цього сервісу — сервера. Взаємодія між клієнтом і сервером стандартизується, так що сервер може обслуговувати клієнтів, реалізованих різними способами й, може бути, різними розроблювачами. При цьому головною вимогою є використання однакового інтерфейсу. Ініціатором обміну звичайно є клієнт, що надсилає запит на обслуговування серверу, що перебуває в стані очікування запиту. Той самий програмний компонент може бути клієнтом стосовно одного виду послуг і сервером для іншого виду послуг. Модель клієнт-сервер є скоріше зручним концептуальним засобом ясного подання функцій того або іншого програмного елемента в якої-небудь ситуації, ніж технологією. Ця модель успішно застосовується не тільки при побудові ОС, але й на всіх рівнях ПЗ й має в деяких випадках більше вузький, специфічний зміст, зберігаючи, природно, при цьому всі свої загальні риси.
За підтримкою монолітних ОС виникає ряд проблем, пов'язаних з тим, що всі функції макроядра працюють у єдиному адресному просторі. По-перше, це небезпека виникнення конфлікту між різними частинами ядра; по-друге - складність підключення до ядра нових драйверів. Перевага мікроядерної архітектури перед монолітною полягає в тім, що кожний компонент системи являє собою самостійний процес, запуск або зупинка якого не відбивається на працездатності інших процесів.
6. Висновок