7.1. Введення: Особливості операційних систем реального часу
При роботі з реальними рухомими пристроями (чим, по суті, і є робот) ми стикаємося з необхідністю якомога швидше реагувати на зовнішні події. Для вирішення цього завдання існує спеціалізований клас операційних систем.
Операційні системи реального часу (ОСРВ) призначені для забезпечення інтерфейсу до ресурсів критичних за часом систем реального часу. Основним завданням в таких системах є своєчасність (timeliness) виконання обробки даних.
В якості основного вимоги до ОСРВ висувається вимога забезпечення передбачуваності або детермінованості поведінки системи в найгірших зовнішніх умовах, що різко відрізняється від вимог до продуктивності і швидкодії універсальних ОС. Гарна ОСРВ має передбачувану поведінку при всіх сценаріях системної завантаження (одночасні переривання і виконання потоків).
Існує певна різниця між системами реального часу і вбудованими системами. Від вбудованої системи не завжди потрібно, щоб вона мала передбачувана поведінка, і в такому випадку вона не є системою реального часу. Однак навіть побіжний погляд на можливі вбудовані системи дозволяє стверджувати, що більшість вбудованих систем потребує передбачуваному поведінці, по крайней мере, для деякої функціональності, і таким чином, ці системи можна віднести до систем реального часу.
Прийнято розрізняти системи м'якого (soft) і жорсткого (hard) реального часу. У системах жорсткого реального часу нездатність забезпечити реакцію на будь-які події в заданий час веде до відмов і неможливості виконання поставленого завдання. У більшості російськомовної літератури такі системи називають системами з детермінованим часом. При практичному застосуванні час реакції має бути мінімальним. Системами м'якого реального часу називаються системи, що не підпадають під визначення "жорсткі", тому що в літературі чіткого визначення для них поки немає. Системи м'якого реального часу можуть не встигати вирішувати завдання, але це не призводить до відмови системи в цілому. У системах реального часу необхідне введення деякого директивного терміну (в англомовній літературі - deadline), до закінчення якого завдання повинна обов'язково (для систем м'якого реального часу - бажано) виконатися. Цей директивний термін використовується планувальником завдань як для призначення пріоритету завдання при її запу ську, так і при виборі завдання на виконання.
- ОС повинна бути багатозадачного і допускає витіснення (preemptable),
- ОС повинна володіти поняттям пріоритету для потоків,
- ОС повинна підтримувати передбачувані механізми синхронізації,
- ОС повинна забезпечувати механізм успадкування пріоритетів,
- поведінка ОС має бути відомим і передбачуваним (затримки обробки переривань, затримки перемикання завдань, затримки драйверів і т.д.); це означає, що у всіх сценаріях робочого навантаження системи має бути визначено максимальний час відгуку.
Протягом останніх 25-30 років структура операційних систем еволюціонувала від монолітної до багатошаровій структурі ОС і далі до архітектури клієнт-сервер. При монолітній структурі ОС складається з набору модулів, і зміни одного модуля впливають на інші модулі. Чим більше модулів, тим більше хаосу при експлуатації такої системи. Крім того, неможливо розподілити ОС багатопроцесорні системи. У багатошаровій структурі зміни одного шару впливають на сусідні шари; крім того, звернення через шар неможливо. Для систем реального часу має бути забезпечено пряме звернення до кожного шару ОС, а іноді безпосередньо до апаратури.
Основною ідеєю клієнт-серверної технології в ОС є зведення базису ОС до мінімуму (планувальник і примітиви синхронізації). Вся інша функціональність виноситься на інший рівень і реалізується через потоки або завдання. Сукупність таких серверних завдань відповідає за системні виклики. Додатки є клієнтами, які запитують сервіси через системні виклики.
Клієнт-серверна технологія дозволяє створювати масштабовані ОС і спрощує розподіл багатопроцесорні системи. При експлуатації системи заміна одного модуля не викликає ефекту "сніжного кома"; крім того, збій модуля не завжди тягне за собою відмову системи в цілому. З'явилася можливість динамічного завантаження і відвантаження модулів. Головною проблемою в цій моделі є захист пам'яті. оскільки серверні процеси повинні бути захищені. При кожному запиті сервісу система повинна перемикатися з контексту програми на контекст сервера. За підтримки захисту пам'яті час перемикання з одного процесу на інший збільшується.
Як правило, більшість сучасних ОСРВ побудовано на основі мікроядра (kernel або nucleus), яке забезпечує планування і диспетчеризацію завдань, а також здійснює їх взаємодія. Незважаючи на зведення до мінімуму в ядрі абстракцій ОС, микроядро все ж має мати уявлення про абстракції процесу. Всі інші концептуальні абстракції операційних систем винесені за межі ядра, викликаються за запитом і виконуються як додатки.
Розглянемо концептуальні абстракції операційної системи через призму вимог до систем реального часу.
7.2. Процеси, потоки, завдання
Отже, в системах реального часу процес розпадається на завдання або потоки. У будь-якому випадку кожен процес розглядається як додаток. Між цими додатками не повинно бути занадто багато взаємодій, і в більшості випадків вони мають різну природу - жорсткого реального часу, м'якого реального часу, не реального часу.
7.3. Планування, пріоритети
У зв'язку з проблемою дедлайнів головною проблемою в ОСРВ стає планування завдань (scheduling), яке забезпечувало б передбачувана поведінка системи при будь-яких обставин. Процес з дедлайнами повинен стартувати і виконуватися так, щоб він не пропустив жодного свого дедлайну. Якщо це неможливо, процес повинен бути відхилений.
У зв'язку з проблемами планування в ОСРВ вивчаються і розвиваються два підходи - статичні алгоритми планування (RMS - Rate Monotonic Scheduling) і динамічні алгоритми планування (EDF - Earliest Deadline First).
RMS використовується для формального докази умов передбачуваності системи. Для реалізації цієї теорії необхідне планування на основі пріоритетів, переривають обслуговування (preemptive priority scheduling). В теорії RMS пріоритет заздалегідь призначається кожному процесу. Процеси повинні відповідати таким вимогам:
- процес має бути завершений за час його періоду,
- процеси не залежать один від одного,
- кожному процесу потрібно однакове процесорний час на кожному інтервалі,
- у неперіодичних процесів немає жорстких термінів,
- переривання процесу відбувається за обмежений час.
Процеси виконуються відповідно до пріоритетів. При плануванні RMS перевага віддається завданням з найкоротшими періодами виконання.
У EDF пріоритет присвоюється динамічно, і найбільший пріоритет виставляється процесу, у якого залишилося найменше час виконання. При великих завантаженнях системи у EDF є переваги перед RMS.
У всіх системах реального часу потрібно політика планування. керована дедлайнами (deadline -driven scheduling). Однак цей підхід знаходиться в стадії розробки.
Зазвичай в ОСРВ використовується планування з пріоритетами, переривають обслуговування, яке засноване на RMS. Пріоритетне переривання обслуговування (preemption) є невід'ємною складовою ОСРВ, тому що в системі реального часу повинні існувати гарантії того, що подія з високим пріоритетом буде оброблено перед подією більш низького пріоритету. Все це веде до того, що ОСРВ потребує не тільки в механізмі планування на основі пріоритетів, переривають обслуговування, але також і в відповідному механізмі управління переривань. Більш того, ОСРВ повинна бути здатна забороняти переривання, коли необхідно виконати критичний код, який не можна переривати. Тривалість обробки переривань повинна бути зведена до мінімуму.
ОСРВ повинна володіти розвиненою системою пріоритетів. По-перше, це потрібно тому, що система сама може розглядатися як набір серверних додатків, що підрозділяються на потоки, і кілька високих рівнів пріоритетів повинно бути виділено системним процесам і потокам. По-друге, в складних додатках необхідно всі потоки реального часу поміщати на різні пріоритетні рівні, а потоки не реального часу поміщати на один рівень (нижче, ніж будь-які потоки реального часу). При цьому потоки не реального часу можна обробляти в режимі циклічного планування (RRS - round-robin scheduling), при якому кожному процесу надається квант часу процесора, а коли квант закінчується, контекст процесу зберігається, і він ставиться в кінець черги. У багатьох ОСРВ для планування завдань на одному рівні використовується RRS. Пріоритетний рівень 0 зазвичай використовується для холостого режиму.
При плануванні на основі пріоритетів необхідно вирішити дві обов'язкові проблеми:
- забезпечити виконання процесу з найвищим пріоритетом,
- не допустити інверсії пріоритетів, коли завдання з високими пріоритетами очікують ресурси, захоплені завданнями з більш низькими пріоритетами.
Для боротьби з інверсією пріоритетів в ОСРВ часто використовується механізм успадкування пріоритетів, однак при цьому доводиться відмовлятися від планування на основі RMS. оскільки пріоритети стають динамічними.