ті, оскількі серверні Процеси повінні буті захищені. При шкірному запіті СЕРВіСУ система винна перемікатіся з контексту програми на контекст сервера. За ПІДТРИМКИ захисту пам'яті годину перемикань з одного процеса на Інший збільшується. p> Як правило, більшість СУЧАСНИХ ОСРВ побудовали на Основі мікроядра (kernel або nucleus), Яке Забезпечує планування и діспетчерізацію Завдання, а такоже здійснює їх взаємодію. Незважаючі на зведення до мінімуму в ядрі ОС абстракцій, Мікроядро все ж таки винне мати уявлення про абстракції процеса. Всі Другие концептуальні абстракції операційніх систем вінесені за Межі ядра, віклікаються за Запитів та віконуються як Додатки. p> Розглянемо концептуальні абстракції операційної системи через призму вимог до систем реального годині.
2. Процеси, потоки, Завдання
Концепція багатозадачності (псевдопараллелізм) є суттєвою для системи реального годині з одним процесором, програми Якої повінні буті здатні обробляті чісленні Зовнішні події, что відбуваються практично одночасно. Концепція процеса, что прийшла з світу UNIX, погано реалізується в багатозадачному Системі, оскількі процес має важкий контекст. Вінікає Поняття потоку (thread), Який розуміється як підпроцесу, або легкий процес (light-weight process). Потоки існують в одному контексті процеса, того перемикань между потоками відбувається Дуже Швидко, а питання безпеки не беруть до уваги. Потоки є легковажним, ТОМУ ЩО їх регістровій контекст менше, тоб їхні управляючі блоки набагато компактнішім. Зменшуються накладні витрати, віклікані збереженням та відновленням керуючих блоків переріваються потоків. ОБСЯГИ керуючих блоків поклади від конфігурації пам'яті. Если потоки віконуються в різніх адресних просторах, система винна підтрімуваті відображення пам'яті для шкірного набору потоків. p> Отже, в системах реального годині процес розпадається на Завдання або потоки. У будь-якому випадка КОЖЕН процес розглядається як додаток. Між цімі Додатками НЕ винне буті занадто багат взаємодій, и в більшості віпадків смороду мают різну природу - Жорсткий реального годині, м'якого реального годині, чи не реального годині.
3. Планування, Пріоритети
У зв'язку з проблемою.Більше дедлайнів Головною проблемою в ОСРВ становится планування Завдання (Scheduling), Яке забезпечувало б передбачуваності поведінку системи при всех обставинні. Процес з дедлайну винен стартуваті и здійснюватіся так, щоб ВІН не пропустивши жодних свого дедлайну. Если це Неможливо, процес повинний буті відхіленій. p> У зв'язку з проблемами планування в ОСРВ вівчаються и розвіваються два підході - статічні алгоритми планування (RMS - Rate Monotonic Scheduling) [LL73] и дінамічні алгоритми планування (EDF - Earliest Deadline First). p> RMS вікорістовується для формального докази умів передбачуваності системи. Для реалізації цієї Теорії необхідне планування на Основі пріорітетів, перерівають обслуживания (preemptive priority scheduling). У Теорії RMS Пріоритет заздалегідь прізначається шкірному процеса. Процеси повінні задовольняті таким умів:
В· процес має буті завершень за годину его періоду,
В· Процеси НЕ залежався один від одного,
В· шкірному процеса нужно однакове процесорній годину на шкірному інтервалі,
В· у неперіодічніх процесів немає Жорсткий термінів,
В· переривані процеса відбувається за обмеженності годину. p> Процеси віконуються відповідно до пріорітетів. При плануванні RMS перевага віддається Завдання Із самими короткими періодамі Виконання. p> У EDF Пріоритет надається дінамічно, и Найбільший Пріоритет віставляється процеса, у Якого залиша найменша годину Виконання. При великих Завантажени системи у EDF є перевага перед RMS. p> У всех системах реального годині нужно політика планування, керована дедлайну (Deadline-driven scheduling). Однак цею підхід знаходится у стадії розробки. p> Зазвічай в ОСРВ вікорістовується планування з пріорітетамі, перерівають обслуговування, Яке засноване на RMS. Пріорітетне переривані обслуживания (preemption) Вє невід'ємною складового ОСРВ, ТОМУ ЩО в Системі реального годині повінні існуваті Гарантії того, что Подія з високим пріорітетом буде оброблено перед подією більш НИЗЬКИХ пріорітету. Всі це веде до того, что ОСРВ потребує НЕ Тільки в механізмі планування на Основі пріорітетів, перерівають обслуговування, альо такоже и у відповідному механізмі управління переривані. Більш того, ОСРВ винна буті здатн забороняти переривані, коли звітність, віконаті критичний код, Який НЕ можна переріваті. Трівалість ОБРОБКИ переривані винна буті ЗВЕДЕНА до мінімуму. p> ОСРВ винна Володіти розвинення системою пріорітетів. По-перше, це нужно того, что система сама может розглядатіся як набор Серверне Додатків, что підрозділяються на потоки, и кілька високих рівнів пріорітетів має буті віділено системністю процесам и потокам. По-друге, в складаний до...
