spz / spz

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

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

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

Ступінь наближення до «ідеального» віртуальній машині може бути більшої або меншої в кожному конкретному випадку. Чим більше віртуальна машина, реалізована засобами ОС на базі конкретних апаратур, наближена до «ідеального» по характеристиках машині й, отже, чим більше її архітектурнологічні характеристики відмінні від реально існуючих, тим більше ступінь віртуальності в отриманої користувачем машини.

Одним з аспектів виртуализации є організація можливості виконання в даної ОСС додатків, які розроблялися для інших ОС.

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

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

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

Спулінг

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

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

Реалізація спулінга досить проста: кожен віртуальний пристрій моделюється деякою частиною зовнішньої пам'яті, як правило дисковою. Щодо змісту, кожна така ділянка пам'яті являє собою буфер між реальним пристроєм введення/виведення та відповідним процесом. Як правило, вхідний буфер заповнюється даними, що зчитуються із реального пристрою введення. Вихідний буфер накопичує дані по мірі виконання процесом команд виведення За цими командами дані пересилаються не на пристрій виведення, а у вихідний буфер. Однак для відповідного процесу виникає ілюзія того, що він здійснив виведення на реальний пристрій. Фактична передача даних відбувається тільки після того, як закінчиться процес (або сукупність процесів), які є постачальниками інформації у вихідний буфер. При мультипрограмній обробці в системі існують одночасно декілька вхідних та вихідних буферів. При цьому Їх заповнення, моменти готовності використання процесами вхідних буферів та моменти завершення процесами вихідних буферів постійно змінюються. Вхідні та вихідні буфери зв'язані у відповідну чергу, яка обслуговується у відповідному порядку. У результаті використання віртуалізації при організації спулінга досягаються досить відчутні результати в роботі ОС Операції введення/виведення (віртуальні по суті) виконуються скоріше та не затримують розвиток процесу внаслідок недосягненості реального пристрою введення/виведення. Отже, можна спланувати та забезпечити рівномірне завантаження пристроїв введення/виведення.

Принцип відкритої й нарощуваної ОС

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

Принцип забезпечення безпеки обчислень

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

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

Забезпечення захисту інформації від несанкціонованого доступу є обов'язковою функцією мережних операційних систем. У багатьох сучасних ОС гарантується ступінь безпеки даних, що відповідає рівню С2 у системі стандартів США. Основи стандартів в області безпеки були закладені в документі «Критерії оцінки надійних комп'ютерних систем». Цей документ виданий Національним центром комп'ютерної безпеки (National computer Security Center) у США в

1983 році, часто називають жовтогарячою книгою.

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

Иерархия рівнів безпеки, наведена в Жовтогарячій книзі, позначають низшийший рівень безпеки як D, а вищий - як А.

У клас D попадають системи, оцінка яких виявила їхню невідповідність вимогам всіх інших класів.

Основними властивостями, характерними для систем класу С, є наявність підсистеми обліку подій, пов'язаних з безпекою, і виборчий контроль доступу. Клас (рівень) С ділиться на 2 підрівня: рівень С1, що забезпечує захист даних від помилок користувачів, але не від дій зловмисників; і більше строгий рівень С2. На рівні С2 повинні бути присутнім:

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

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

•засоби обліку й спостереження (auditing), що забезпечують можливість виявити й зафіксувати важливі події, пов'язані з безпекою, або будь-які спроби створити, одержати доступ або видалити системні ресурси;

•захист пам'яті, що полягає в тім, що пам'ять инициализируется перед тим, як повторно використається.

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

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

Рівень А є найвищим рівнем безпеки, він вимагає на додаток до всіх вимог рівня У виконання формального, математично обґрунтованого доказу відповідності системи вимогам безпеки.

Різні комерційні структури (наприклад, банки) особливо виділяють необхідність облікової служби, аналогічної тієї, що пропонують державні рекомендації С2. Будь-яка діяльність, пов'язана з безпекою, може бути отслежена й тим самим врахована. Це саме те, чого вимагає стандарт для систем класу З2, і що звичайно потрібно банкам. Однак комерційні користувачі, як Правило, не хочуть розплачуватися продуктивністю за підвищений рівень безпеки. А-рівень безпеки займає своїми керуючими механізмами до 90 % процесорного часу, що, безумовно, у більшості випадків уже неприйнятно.

Более безпечні системи не тільки знижують ефективність, але й істотно обмежують число доступних прикладних пакетів, відповідним чином можуть виконуватися в подібній системі. Hапример для ОС Solaris (версія UNIX) є кілька тисяч додатків, для її В рівня - тільки біля ста.

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. Поводження ОС повинно бути відомо і досить точно прогнозовано.

Час виконання системних викликів і тимчасові характеристики поводження системи в різних обставинах повинні бути відомі розроблювачу. Тому розробник ОСРЧ повинний приводити наступні характеристики:

латентну затримку переривання (то час від моменту переривання до моменту запуску задачі): вона повинна бути передбачувана і погоджена з вимогами додатка. Ця величина залежить від числа одночасно «висячих» переривань;

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

максимальний час маскування переривань драйверами й ОС.