Коли планувальник процесів отримує управління, його основним завданням є вибір наступного процесу, який повинен отримати управління. Алгоритми, що лежать в основі цього вибору, визначають дисципліну диспетчеризації, прийняту в даній ОС.
Однією з найбільш очевидних дисциплін є проста кругова диспетчеризація (round robin scheduling). Її суть в наступному. Всі активні процеси вважаються рівноправними і утворюють кругову чергу. Кожен процес отримує від системи квант часу, після закінчення якого планувальник вибирає для виконання наступного процес з черги. Таким чином, якщо всі процеси залишаються активними, то система забезпечує їх рівномірне просування, що імітує паралельне виконання всіх процесів. Якщо поточний процес блокується, він випадає з кола і потрапляє в список сплячих процесів. Коли система активізує один з сплячих процесів, він включається в кругову чергу.
У певному сенсі протилежною дисципліною є фоново-оперативна диспетчеризація (foreground / background scheduling) - одна з найстаріших форм організації багатозадачного роботи. У найпростішому випадку вона включає два процеси: фоновий процес і оперативний процес (процес переднього плану). Фоновий процес виконується тільки тоді, коли спить оперативний процес. При активізації оперативного процесу відбувається негайне витіснення фонового, тобто оперативний процес має більш високий абсолютний пріоритет. Зазвичай при такій дисципліні передбачається, що активізація оперативного процесу не зажадає багато процесорного часу, так що виконання фонового процесу буде скоро відновлено. Одним із прикладів ефективного використання фоново-оперативної диспетчеризації є так звана «фонова друк», яку дозволяє виконати навіть однозадачная MS-DOS. При цьому процес виведення файлу на принтер розглядається як процес переднього плану, а звичайна діалогова робота з ОС - як фоновий процес. Оскільки обслуговування переривань від принтера займає лише долі відсотка процесорного часу, користувач не відчуває ніякого уповільнення роботи.
Між описаними двома крайнощами лежить велика різноманітність дисциплін пріоритетною диспетчеризації. Всі вони засновані на приписуванні кожному процесу при його створенні деякого числа - пріоритету. Більш високий пріоритет повинен давати процесу певні переваги перед низькопріоритетних процесами при роботі планувальника.
Призначення пріоритетів виконується користувачем або адміністратором системи, можливо також програмне зміна пріоритету процесу. На вибір оптимального рівня пріоритету впливають в основному два міркування:
· Важливість, відповідальність даного процесу або привілейоване становище запускає процес користувача;
· Кількість процесорного часу, на яке буде претендувати процес (як ми бачили в прикладі з фоновою печаткою, високий пріоритет процесу, мало завантажує процесор, майже не призводить до уповільнення роботи інших процесів).
Основний алгоритм пріоритетного планування нагадує просте кругове планування, проте кругова чергу активних процесів формується окремо для кожного рівня пріоритету. Поки є хоч один активний процес в черзі з найвищим пріоритетом, процеси з більш низькими пріоритетами не можуть отримати управління. Тільки коли всі процеси з вищим пріоритетом заблоковані або завершені, планувальник вибирає процес з черги з більш низьким пріоритетом.
Пріоритет, який присвоюється процесу при створенні, називається статичним пріоритетом. Дисципліна планування, що використовує тільки статичні пріоритети, має один істотний недолік: низькопріоритетні процеси можуть надовго опинитися повністю відлученими від процесора. Іноді це прийнятно (якщо високопріоритетні процеси незрівнянно важливіше, ніж низькопріоритетні), однак частіше хотілося б, щоб і на низькі пріоритети хоч що-небудь перепадало, нехай навіть рідше і в меншій кількості, ніж на високі. Для вирішення цього завдання запропоновано безліч різних алгоритмів планування процесів, заснованих на ідеї динамічного пріоритету.
Динамічний пріоритет процесу - це величина, автоматично розраховується системою на основі двох основних чинників: статичного пріоритету і ступеня попереднього використання процесора даним процесом. Загальна ідея наступна: якщо процес занадто довго не отримував процесорного часу, то його пріоритет слід підвищити, щоб дати процесові шанс на майбутнє. Навпаки, якщо процес занадто часто і довго працював, є сенс тимчасово знизити його пріоритет, щоб пропустити вперед зголоднілих конкурентів.
Можуть враховуватися й інші міркування, що впливають на динамічний пріоритет. Наприклад, якщо процес веде діалог з користувачем, то має сенс підвищити його пріоритет, щоб скоротити час реакції і уникнути прикрих затримок при натисканні клавіш. Якщо процес останнім часом часто блокувався, не використавши до кінця виділений йому квант часу, то це теж підстава для підвищення пріоритету: цілком можливо, процес і надалі буде так само невибагливий.