4.3.2 Пріоритетне планування
Кожному процесу привласнюється пріоритет, і управління передається процесу з найвищим пріоритетом.
Пріоритет може бути динамічний і статичний.
Динамічний пріоритет може встановлюватися так:
П=1/Т, де Т- частина використаного кванта
Якщо використано 1/50 кванта, то пріоритет 50.
Якщо використаний весь квант, то пріоритет 1.
Тобто процеси обмежені вводом/виводом, матимуть пріоритет над процесами обмеженими процесором.
Часто процеси об'єднують по пріоритетах в групи, і використовують пріоритетне планування серед груп, але усередині групи використовують циклічне планування.
Пріоритетне планування 4-х груп
4.3.3 Методи розділення процесів на групи
Групи з різним квантом часу
Спочатку процес потрапляє в групу з найбільшим пріоритетом і найменшим квантом часу, якщо він використовує весь квант, то потрапляє в другу групу і т.д. Щонайдовші процеси опиняються в групі найменшого пріоритету і найбільшого кванта часу.
Процес або закінчує роботу, або переходить в іншу групу
Цей метод нагадує алгоритм - "Найкоротше завдання - перша".
Групи з різним призначенням процесів
Процес що відповідає на запит, переходить в групу з найвищим пріоритетом.
Такий механізм дозволяє підвищити пріоритет роботи з клієнтом.
Гарантоване планування
У системі з n-процесами, кожному процесу буде надано 1/n часу процесора.
Лотерейне планування
Процесам лунають "лотерейні квитки" на доступ до ресурсів. Планувальник може вибрати будь-який квиток, випадковим чином. Чим більше квитків у процесу, тим більше у нього шансів захопити ресурс.
Справедливе планування
Процесорний час розподіляється серед користувачів, а не процесів. Це справедливо якщо у одного користувача декілька процесів, а у іншого один.
4.4 Планування в системах реального часу
Системи реального часу діляться на:
жорсткі (жорсткі терміни для кожного завдання) - управління рухом
гнучкі (порушення тимчасового графіка не бажані, але допустимі) - управління відео і аудіо
Зовнішні події на які система повинна реагувати, діляться:
періодичні - потокове відео і аудіо
неперіодичні (непередбачувані) - сигнал про пожежу
Що б систему реального часу можна було планувати, потрібне щоб виконувалася умова:
m - число періодичних подій
i - номер події
P(i) - період надходження події
T(i) - час, який йде на обробку події
Тобто переобтяжена система реального часу є не планованою
4.4.1 Планування однорідних процесів
Як однорідні процеси можна розглянути відео сервер з декількома відео потоками (декілька користувачів дивляться фільм).
Оскільки всі процеси важливі можна використовувати циклічне планування.
Але оскільки кількість користувачів і розміри кадрів можуть мінятися, для реальних систем він не підходить.
4.4.2 Загальне планування реального часу
Використовується модель, коли кожен процес бореться за процесор з своїм завданням і графіком його виконання.
Планувальник повинен знати:
частота, з якою повинен працювати кожен процес
об'єм робіт, який йому належить виконати
найближчий термін виконання чергової порції завдання
Розглянемо приклад з трьох процесів.
Процес А запускається кожні 30мс, обробка кадру 10мс
Процес В частота 25 кадрів, тобто кожні 40мс, обробка кадру 15мс
Процес С частота 20 кадрів, тобто кожні 50мс, обробка кадру 5мс
Три періодичні процеси
Перевіряємо, чи можна планувати ці процеси.
10/30+15/40+5/50=0.808<1
Умова виконується, планувати можна.
Плануватимемо ці процеси статичним (пріоритет наперед призначається кожному процесу) і динамічним методами.
4.4.3 Статичний алгоритм планування RMS (Rate Monotonic Scheduling)
Процеси повинні задовольняти умовам:
Процес повинен бути завершений за час його періоду
Один процес не повинен залежати від іншого
Кожному процесу потрібен однаковий процесорний час на кожному інтервалі
У неперіодичних процесів немає жорстких термінів
Переривання процесу відбувається миттєво
Пріоритет в цьому алгоритмі пропорційний частоті.
Процесу А він рівний 33 (частота кадрів)
Процесу В він рівний 25
Процесу С він рівний 20
Процеси виконуються по пріоритету.
4.4.4 Динамічний алгоритм планування EDF (Earliest Deadline First)
Найбільший пріоритет виставляється процесу у якого залишився найменший час виконання.
При великих завантаженнях системи EDF має переваги.
Розглянемо приклад, коли процесу А потрібний для обробки кадру 15мс.
Перевіряємо, чи можна планувати ці процеси.
15/30+15/40+5/50=0.975<1
Завантаження системи 97.5%
Алгоритм планування RMS терпить невдачу.
Коли користувач запускає програму на виконання, створюється новий процес який забезпечує її виконання. Процес існує в системі доти, поки він не буде перерваний: або самим собою добровільно, або ядром, або за вимогою користувача. Процес сам є абстракцією, що надає ядро для керування програмою під час її виконання. Процес може до деякої міри контролюватися через системні виклики, що впливають, наприклад, на пріоритет виконання процесу.
Через абстракцію процесу ядро дає програмі ілюзію, що вона сама безпосередньо виконується апаратурою. Користувальницька програма не зобов'язана тепер піклуватися про взаємодію з іншими програмами, виконуваними системою, якщо тільки їй явно не буде потрібно зв'язок між ними яким-небудь способом. Кожен процес має свій власний віртуальний адресний простір і роздроблений у часі так, що кілька процесів можуть розділяти між собою апаратні ресурси. Існування інших процесів у системі прозоро для користувальницької програми. Це спрощує розробку нових програм і допомагає підтримувати переносимість програм на інші комп'ютерні системи.
Поділ часу між процесами, забезпечуваний ядром протягом усього періоду активності системи, незалежного від того, на якому рівні - користувача чи ядра, виконується в рамках контексту деякого процесу. При використанні традиційної політики поділу часу , виконання процесу на рівні користувача може бути роздроблене в будь-який момент, для того, щоб забезпечити використання ресурсів ЦП більш-менш рівномірно між усіма процесами. Процеси, що виконуються на рівні ядра виключаються з дроблення за часом. Переключення до іншого процесу при виконанні на рівні ядра відбувається тільки якщо поточний процес ядра явно дозволяє цьому відбутися.
Одним з виключень із правила, що вся активність системи відбувається в рамках процесів, є виконання оброблювачів переривань. Переривання генеруються пристроями введення/виводу, коли в них виникає інформація про статус, що повинна бути передана операційній системі. Інформація про статус може включати, наприклад, код закінчення операції введення/виводу. Переривання виконуються асинхронно стосовно процесів, у тім змісті, що вони можуть виникнути без попередження в будь-який момент часу. Коли вони виникають, ядро дозволяє їм перервати виконання поточного процесу. Система потім виконує оброблювач переривань до його завершення, чи доти, поки він не буде перерваний перериванням більш високого пріоритету. Процеси рівня ядра мають привілей блокування переривань, якщо це необхідно. Це робиться тільки для захисту цілісності структур даних, поділюваних між рівнем процесу і кодом оброблювача переривань.
Інше виключення з цього правила виникає у випадку сервісних процедур обслуговуючих потоки введення/виводу (streams - не плутати з потоками керування - threads у процесі). Механізм потоків уведення/виводу складає основу для реалізації мережних протоколів, і ці сервісні процедури виконуються поза контекстом якого-небудь процесу, майже як оброблювачі переривань, з розумінь підвищення продуктивності й ефективності системи.