1
Мікроядерні та монолітні операційні системи
1.Мікроядерні операційні системи
2.Монолітні операційні системи
3.Вимоги до ОС реального часу
3.1.Мультипрограмність і багатозадачність
3.2.Пріоритети задач (потоків)
3.3.Спадкування пріоритетів
3.4.Синхронізація процесів і задач
3.5.Передбачуваність
Мікроядерні операційні системи
Мікроядро — це мінімальна головна частина операційної системи, яка служить основою модульних розширень і розширень, що переміщуються. Існує думка, що більшість операційних систем наступних поколінь будуть мати мікроядра. Однак є маса різних думок із приводу того, як варто організовувати служби операційної системи стосовно мікроядра: як проектувати драйвери пристроїв, щоб домогтися найбільшої ефективності, але зберегти функції драйверів максимально незалежними від апаратури; чи варто виконувати операції, що не відносяться до ядра, у просторі чи ядра в просторі користувача; чи варто зберігати програми існуючих підсистем (наприклад, Unix) чи краще відкинути всі і почати з нуля.
Основна ідея, закладена в технологію мікроядра, полягає в тому, щоб конструювати необхідне середовище верхнього рівня, з якого можна легко одержати доступ до усіх функціональних можливостей рівня апаратного забезпечення. При такій структурі ядро служить стартовою крапкою для створення системи. Мистецтво розробки мікроядра полягає у виборі базових примітивів, які повинні в ньому знаходитися для забезпечення необхідного і достатнього сервісу. У мікроядрі міститься і виповнюється мінімальна кількість коду, необхідне для реалізації основних системних викликів. У число цих викликів входять передача повідомлень і організація іншого спілкування між зовнішніми стосовно мікроядра процесами, підтримка керування перериваннями, а також ряд деяких інших функцій. Інші функції, характерні для «звичайних» (не мікроядерних) ОС, забезпечуються як модульні доповнення-процеси, взаємодіючі головним чином між собою і здійснюючі взаємодію за допомогою передачі повідомлень.
Мікроядро є маленьким модулем, який передає повідомлення системного програмного забезпечення та працює в найбільш пріоритетному стані комп’ютера і підтримує іншу частину операційної системи, розглянуту
2
як набір серверних додатків. Інтерес до мікроядер зростав у міру того, як системні розроблювачі реагували на складність сучасних реалізацій операційних систем і успішну демонстрацію реалізуємості концепції мікроядра.
Створена в університеті Карнегі Меллон технологія мікроядра Масh є основою для багатьох ОС.
Виконувані мікроядром функції обмежені з метою скорочення його розмірів і максимізації кількості коду, що працює як прикладна програма. Мікроядро включає тільки ті функції, що вимагаються для визначення набору абстрактних середовищ обробки для прикладних програм і для організації спільної роботи додатків у забезпеченні сервісів і в дії клієнтами і серверами.
Урезультаті мікроядро забезпечує тільки п'ять різних типів сервісів:
керування віртуальною пам'яттю;
завдання і потоки;
межпроцесні комунікації (IРС);
керування підтримкою введення/виведення і перериваннями;
сервіси набору хоста і процесора.
Інші підсистеми і функції операційної системи, такі як системи керування файлами, підтримка зовнішніх пристроїв і традиційні програмні інтерфейси, розміщаються в одному чи більше системних сервісах або в задачі операційної системи. Ці програми працюють як додатки мікроядра.
Мікроядро створює прикладне середовище, що забезпечує використання мультипроцесорів без вимоги, щоб якась конкретна машина була мультипроцессорною.
Уся підтримка, необхідна для мультипроцессорних машин, сконцентрована в порівняно малому і простому мікроядрі.
Завдяки своїм розмірам і здатності підтримувати стандартні сервіси програмування і характеристики у вигляді прикладних програм самі мікроядра простіші, ніж ядра монолітних чи модульних операційних систем.
Оскільки мікроядра малі і мають порівняно мало необхідного до виконання коду рівня ядр вони забезпечують зручний спосіб підтримки характеристик реального часу, що вимагаються для мультимедиа, керування пристроями і високошвидкісними комунікаціями.
Добре структуровані мікроядра забезпечують ізолюючий шар для апаратних розходжень, які не маскуються застосуванням мов програмування високого рівня. Таким чином, вони спрощують перенесення коду і збільшують рівень його повторного використання.
Найбільш яскравим представником мікроядерних ОС є ОС реального часу QМХ (одна з різновидностей Юниксу – викор. на атомних станціях).
3
Мікроядро QМХ підтримує тільки планування і диспетчеризацію процесів, взаємодію процесів, обробку переривань і мережні служби нижнього рівня. Мікроядро забезпечує усього лише пару десятків системних викликів, але завдяки цьому воно може бути цілком розміщене у внутрішньому кэші навіть таких процесорів, як Inte1 486. Різні версії цієї ОС мали і різні обсяги ядер — від 8 до 46 Кбайт.
Щоб побудувати мінімальну систему QМХ, потрібно додати до мікроядра менеджер процесів, який створює процеси, керує процесами і пам'яттю процесів. Щоб ОС QМХ була застосовна не тільки у вбудованих і бездискових системах, потрібно додати файлову систему і менеджер пристроїв. Ці менеджери виконуються поза простором ядра, так що ядро залишається невеликим.
Монолітні операційні системи
Монолітні ОС є прямою протилежністю мікроядерним ОС. У монолітної ОС, незважаючи на її можливу сильну структуризацію, дуже важко видалити один з рівнів багаторівневої модульної структури. Додавання нових функцій і зміна існуючих для монолітних ОС вимагає дуже гарного знання всієї архітектури ОС і надзвичайно великих зусиль. Тому більш сучасний підхід до проектування ОС, що може бути умовно названий як «клієнт-серверна» технологія, дозволяє в більшій мері і з меншими трудозатратами реалізувати перераховані вище принципи проектування ОС.
Модель клієнт-сервер припускає наявність програмного компонента, що є споживачем якого-небудь сервісу — клієнта, і програмного компонента, що служить постачальником цього сервісу — сервера. Взаємодія між клієнтом і сервером стандартизується, так що сервер може обслуговувати клієнтів, реалізованих різними способами і різними розроблювачами. При цьому головною вимогою є використання однакового інтерфейсу. Ініціатором обміну звичайно є клієнт, який надсилає запит на обслуговування серверу, що знаходиться в стані чекання запиту.
Той самий програмний компонент може бути клієнтом по відношенню до одного виду послуг і сервером для іншого виду послуг.
При підтримці монолітних ОС виникає ряд проблем, пов’язаних з тим, що всі функції макроядра працюють в єдиному адресному просторі. Поперше, це небезпека виникнення конфлікту між різними частинами ядра. Подруге – складність підключення до ядра нових драйверів. Перевага мікроядерної архітектури перед монолітною в тому, що кожний компонент системи представляє собою самостійний процес, запуск або зупинка якого не відображається на працездатності решти ресурсів.
В даний час мікроядерні ОС розроблюються частіше монолітних.
4
Вимоги до ОС реального часу
Система реального часу повинна давати відгук на любі зовнішні впливи на протязі передбачуваного інтервалу часу. Для цього повинні бути забезпечені наступні властивості:
обмеження часу відгуку, тобто після настання події реакція на нього гарантовано буде до встановлення крайнього терміну. Відсутність такого обмеження розглядається як серйозний недолік програмного забезпечення.
одночасність обробки: навіть якщо надходить більше однієї події одночасно, то всі часові обмеження для всіх подій повинні бути витримані. Це означає, що системі реального часу повинен бути властивий паралелізм. Паралелізм досягається використанням декількох процесорів в системі і/або багатозадачного підходу.
Прикладами систем реального часу є системи керування атомними електростанціями або якимись технологічними процесами, медичного моніторингу, керування озброєнням, космічної навігації, розвідки, керування лабораторними експериментами, керування автомобільними двигунами, робототехніка, системи антиблокування гальм, системи сигналізації ….
Іноді можна почути, що розрізняють системи “м’якого” і “жорсткого” реального часу. Різниця між жорсткою і м’якою СРЧ залежить від вимог до системи. Система рахується жорсткою, якщо не допускається порушення часових обмежень, і м’якою, якщо порушення часових обмежень небажано.
( Ведеться безліч дискусій про точний зміст термінів «тверда» і «м'яка» СРЧ. Можна навіть аргументувати, що м'яка СРЧ не є СРЧ зовсім, тому що основна вимога дотримання тимчасових обмежень не виконана. У дійсності термін СРЧ часто неправомірно застосовують стосовно швидких систем.)
Отже, перелічимо основні вимоги до ОСРЧ.
Мультипрограмність і багатозадачність
Вимога 1. ОС повинна бути мультипрограмною і многозадачною (багатопоточною) і активно використовувати переривання для диспетчеризації.
ОСРЧ повинна бути передбачуваною. Це означає не те, що ОСРВ повинна бути швидкою, а те, що максимальний час виконання тієї чи іншої дії повинний бути відомий заздалегідь і повинен відповідати вимогам додатка. Так, наприклад, ОС Windows 3.11 навіть на Pentium III 1000 МНz марна для ОСРЧ, тому що один додаток може захопити керування і заблокувати систему для інших.
5
Перша вимога полягає в тому, що ОС повинна бути багатопоточною за принципом абсолютного пріоритету ( що переривається). Тобто планувальник повинний мати можливість перервати будь-який потік і надати ресурс тому потоку, якому він найбільш необхідний. ОС (і апаратура) повинні також забезпечувати переривання на рівні обробки переривань.
Пріоритети задач (потоків)
Вимога 2. В ОС повинне існувати поняття пріоритету потоку.
Справа в тім, щоб визначити, якій задачі ресурс потрібно найбільше. В ідеальній ситуації ОСРЧ віддає ресурс потоку або драйверу з найближчим крайнім терміном (це називається керуванням тимчасовим обмеженням). Щоб реалізувати це тимчасове обмеження, ОС повинна знати, скільки часу потрібно кожному з потоків, що виконуються, для завершення.
ОС, побудованих по цьому принципі, практично немає, тому що він занадто складний для реалізації. Тому розроблювачі ОС приймають іншу точку зору: вводиться поняття рівня пріоритету для задачі, і тимчасові обмеження зводять до пріоритетів. Показники СРВ при цьому знижуються.
Спадкування пріоритетів
Вимога 3. В ОС повинна існувати система спадкування пріоритетів. Насправді саме цей механізм синхронізації і той факт, що різні треди
використовують той самий простір пам'яті, відрізняють їх від процесів.
Як ми уже знаємо, процеси майже не розділяють те саме простір пам'яті, а в основному працюють у своїх локальних адресних просторах.
Комбінація пріоритетів тредів і поділу ресурсів між ними приводить до іншого явища — класичної проблеми інверсії пріоритетів. Це можна проілюструвати на прикладі, коли є як мінімум три треда. Коли тред нижчого пріоритету захопив ресурс, поділюваний із тредом вищого пріоритету, і почав виконуватися потік середнього пріоритету, виконання треда вищого пріоритету буде припинено, поки не звільниться ресурс і не відробить тред середнього пріоритету. У цій ситуації час, необхідний для завершення треда вищого пріоритету, залежить від нижніх пріоритетних рівнів, — це і є інверсія пріоритетів. Ясно, що в такій ситуації важко витримати обмеження на час виконання.
Щоб усунути такі інверсії, ОСРЧ повинна допускати спадкування пріоритету, тобто підвищення рівня пріоритету треда до рівня треда, що його викликає. Спадкування означає, що ресурс, що блокує, тред успадковує пріоритет треда, що він блокує (зрозуміло, це справедливо лише в тому випадку, якщо блокируемый тред має більш високий пріоритет).
6
Синхронізація процесів і задач
Вимога 4. ОС повинна забезпечувати могутні, надійні і зручні механізми синхронізації задач.
Тому що задачі розділяють дані (ресурси) і повинні контактувати один з одним, логічно, що повинні існувати механізми блокування і комунікації. Необхідні механізми, гарантовано надають можливість паралельно виконуваним задачам і процесам оперативно обмінюватися повідомленнями і синхросигналами. Ці системні механізми повинні бути завжди доступні процесам, що вимагають реального часу. Отже, системні ресурси для їхнього функціонування повинні бути розподілені заздалегідь.
Передбачуваність
Вимога 5. Поводження ОС повинно бути відомо і досить точно прогнозовано.
Час виконання системних викликів і тимчасові характеристики поводження системи в різних обставинах повинні бути відомі розроблювачу. Тому розробник ОСРЧ повинний приводити наступні характеристики:
латентну затримку переривання (то час від моменту переривання до моменту запуску задачі): вона повинна бути передбачувана і погоджена з вимогами додатка. Ця величина залежить від числа одночасно «висячих» переривань;
максимальний час виконання кожного системного виклику. Воно повинно бути передбачуване і не залежно від числа об'єктів у системі;
максимальний час маскування переривань драйверами й ОС.