Реферат: Особливості операційних систем реального часу

2. Процеси, потоки, завдання

Концепція багатозадачності (псевдопараллелізм) є суттєвою для системи реального часу з одним процесором, програми якої повинні бути здатні обробляти численні зовнішні події, що відбуваються практично одночасно. Концепція процесу, що прийшла з світу UNIX, погано реалізується в багатозадачному системі, оскільки процес має важкий контекст. Виникає поняття потоку (thread), який розуміється як підпроцесу, або легкий процес (light-weight process). Потоки існують в одному контексті процесу, тому перемикання між потоками відбувається дуже швидко, а питання безпеки не беруться до уваги. Потоки є легковажно, тому що їх регістровий контекст менше, тобто їхні управляючі блоки набагато компактнішим. Зменшуються накладні витрати, викликані збереженням та відновленням керуючих блоків перериваються потоків. Обсяг керуючих блоків залежить від конфігурації пам'яті. Якщо потоки виконуються в різних адресних просторах, система повинна підтримувати відображення пам'яті для кожного набору потоків.

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

3. Планування, пріоритети

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

У зв'язку з проблемами планування в ОСРВ вивчаються і розвиваються два підходи - статичні алгоритми планування (RMS - Rate Monotonic Scheduling) [LL73] і динамічні алгоритми планування (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, оскільки пріоритети стають динамічними.

4. Пам'ять

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

· Модель без захисту - системне і користувацьким простору не захищені один від одного, використовується два сегменти пам'яті: для коду та для даних; при цьому від системи не потрібно ніякого управління пам'яттю, не потрібно MMU (memory management unit - спеціальне апаратний пристрій для підтримки управління віртуальною пам'яттю).

· Модель захисту система / користувач - системне адресний простір захищене від адресного простору користувача, системні і користувальницькі процеси виконуються в загальному віртуальному адресному просторі, при цьому потрібно MMU. Захист забезпечується сторінковим механізмом захисту. Розрізняються системні і користувальницькі сторінки. Користувальницькі програми ніяк не захищені один від одного. Процесор знаходиться в режимі супервізора, якщо поточний сегмент має рівень 0, 1 або 2. Якщо рівень сегмента - 3, то процесор знаходиться в режимі користувача. У цій моделі необхідні чотири сегменти - два сегменти на рівні 0 (для коду та даних) і два сегменти на рівні 3. Механізм сторінкової захисту не додає накладних витрат, тому що захист перевіряється одночасно з перетворенням адреси, яке виконує MMU; при цьому операційна система не потребує в управлінні пам'яттю.

· Модель захисту користувач / користувач - до моделі система / користувач додається захист між користувацькими процесами; потрібно MMU. Як і в попередній моделі, використовується механізм сторінкової захисту. Усі сторінки позначаються як привілейовані, за винятком сторінок поточного процесу, які позначаються як користувацькі. Таким чином, виконують потік не може звернутися за межі свого адресного простору. ОС відповідає за оновлення прапора привілейованості для конкретної сторінки в таблиці сторінок при перемиканні процесу. Як і в попередній моделі використовуються чотири сегменти.

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

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

Якщо підтримується сторінкова організація пам'яті (paging), відповідне відображення сторінок у фізичні адреси повинно бути частиною контексту процесу. Інакше знову з'являється непередбачуваність, неприйнятна для ОСРВ.