spz / lect / lekc5_3_DD_stat_dynam

Дисципліни диспетчеризації

1.Класифікація ДО.

2.Безпріоритетні ДО: лінійні та циклічні.

3.Пріоритетні ДО: ДО з фіксованим пріоритетом та ДО з абсолютним пріоритетом. Адаптивні ДО.

4.Визначення середнього часу знаходження заявки в системі.

5.Недоліки ДО з фіксованим пріоритетом.

6.Динамічне планування (диспетчеризація).

7.Диспетчеризація задач з використанням динамічних пріоритетів.

8.Переваги і недоліки.

9.Критерії ефективності обчислювального процесу.

10.Методи підвищення продуктивності системи для багатопроцесорних систем. Механізм динамічних пріоритетів в ОС UNIX.

Відома велика кількість правил (дисциплін диспетчеризації), у відповідності з якими формується список (черга) готових до виконання задач.

Розрізняють два великих класи дисциплін обслуговування —

безпріоритетні і пріоритетні. При безпріоритетному обслуговуванні вибір задачі відбувається в деякому заздалегідь установленому порядку без обліку їхньої відносної важливості і часу обслуговування. При реалізації пріоритетних дисциплін обслуговування окремим задачам дається переважне право потрапити в стан виконання. Перелік дисциплін обслуговування і їхня класифікація приведені на рис. 2.1.

Запам'ятаємо про пріоритети наступне:

-пріоритет, привласнений задачі, може бути величиною постійною;

-пріоритет задачі може змінюватися в процесі її рішення.

Диспетчеризація з динамічними пріоритетами вимагає додаткових витрат на обчислення значень пріоритетів задач, що виконуються, тому в багатьох ОС реального часу використовуються методи диспетчеризації на основі статичних (постійних) пріоритетів. Хоча треба помітити, що динамічні пріоритети дозволяють реалізувати гарантії обслуговування задач.

Розглянемо коротко деякі основні (найбільш часто використовувані) дисципліни диспетчеризації.

Найпростіший у реалізації є дисципліна FCFS (first come — firsi served), відповідно до якої задачі обслуговуються «у порядку черги», тобто в порядку їх появи. Ті задачі, що були заблоковані в процесі роботи (потрапили в яке-небудь зі станів очікування, наприклад, через операції введення/виведення), після переходу в стан готовності ставляться в цю чергу готовності перед тими задачами, що ще не виконувалися. Іншими словами, утворяться дві черги (мал. 2.2); одна черга утвориться з нових

задач, а друга черга - з тих, що раніше виконувалися, але, потрапили в стан очікування. Такий підхід дозволяє реалізувати стратегію обслуговування «по можливості закінчувати обчислення в порядку їхньої появи». Ця дисципліна обслуговування не вимагає зовнішнього втручання в хід обчислень, при ній не відбувається перерозподіл процесорного часу.

Дисципліни диспетчеризації

Рис2.1. Дисципліни диспетчиризації

Виконані задачі

Процесор

Блокування

Черга задач, які знову готові до виконання

Черга нових задач

Рис. 2.2. Дисципліна диспетчеризації FCFS

Існуючі дисципліни диспетчеризації процесів можуть бути розбиті на два класи — витісняючі (preemtive) і не витісняючі (nonpreemptive).

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

Ввитісняюча багатозадачність - диспетчеризація з розподілом процесорного часу. Це такий спосіб, при якому, рішення про переключення процесора з однієї задачі на виконання іншого приймається диспетчером задач, а не самим завданням.

У перших пакетних ОС часто реалізовували паралельне виконання завдань без примусового перерозподілу процесора між задачами.

Прикладом ефективного використання не витісняючої багатозадачності є мережева ОС Novell Net Ware, в якій досягнута

також і в ОС для ПК, орієнтованих на високопродуктивне виконання додатків (Windows NT, OS/2, Linux), реалізована витісняюча багатозадачність.

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

завантаження обчислювальної системи росте і середній час чекання обслуговування, причому короткі завдання (потребуючі невеликих

витрат машинного часу) змушені очікувати стільки ж, скільки і трудомісткі завдання. Уникнути цього недоліку дозволяють дисципліни

SJN і SRT.

Дисципліна обслуговування SJN (shortest job next, що означає:

наступним буде виконуватися найкоротше завдання) вимагає, щоб для кожного завдання була відома оцінка в потребах машинного часу. Необхідність повідомляти ОС характеристики задач, у яких описувалися, би потреби в ресурсах обчислювальної системи, привела до того, що були розроблені відповідні мовні засоби. Зокрема, мова JCL (job control language, мова керування завданнями) була одним з найбільш відомих.

Користувачі змушені були вказувати передбачуваний час виконання,

і для того, щоб вони не зловживали можливістю указати свідомо менший час виконання (з метою одержати результати раніш інших), увели підрахунок реальних потреб. Диспетчер задач порівнював замовлений час і час виконання, і у випадку перевищення зазначеної оцінки в даному ресурсі ставив дане завдання не в початок, а в кінець черги.

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

Дисципліна обслуговування SJN припускає, що є тільки одна черга завдань, готових до виконання. І завдання, що у процесі свого виконання були тимчасово заблоковані (наприклад, очікували завершення операцій уведення/виведення), знову попадають у кінець черги готових до виконання нарівні з тими, що тільки надходять. Це приводить до того, що завдання, яким потрібно дуже небагато часу для свого завершення, змушені очікувати процесор нарівні з тривалими задачами, що не завжди добре.

Для усунення цього недоліку і була запропонована дисципліна SRT (shortest remaining time, наступне завдання вимагає менше всього часу для свого завершення).

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

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

Для рішення подібних проблем використовується дисципліна обслуговування, називана RR (round robin, кругова, карусельна), і пріоритетні методи обслуговування.

Дисципліна обслуговування RR припускає, що кожна задача одержує процесорний час порціями (говорять: квантами часу*, q). Після закінчення кванта часу q задача знімається з процесора і він передається наступній задачі. Знята задача ставиться в кінець черги задач, готових до виконання. Ця дисципліна обслуговування ілюструється мал. 2.3. Для оптимальної роботи системи необхідно правильно вибрати закон, по якому кванти часу виділяються задачам.

Виконані задачі

Процесор

Рис. 2.3. Карусельна дисципліна диспетчеризації (round robin)

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

Наприклад, у OS/2 у файлі CONFIG.SYS є можливість за допомогою оператора TIMELSLICE указати мінімальне і максимальне значення для кванта q. Так, наприклад, рядок TIMESLICE=32,256 указує, що мінімальне значення q дорівнює 32 мілісекундам, а максимальне — 256. Якщо деяка задача була перервана, оскільки виділений їй квант часу q витрачений, то наступний виділений йому інтервал буде збільшений на час, рівний одному періоду таймера (близько 32 мс), і так доти, поки квант часу не стане рівним максимальному значенню, зазначеному в TIMELSLICE.

У своїй найпростішій реалізації дисципліна карусельної диспетчеризації припускає, що всі задачі мають однаковий пріоритет. Якщо

ж необхідно ввести механізм пріоритетного обслуговування, то це, як правило, робиться за рахунок організації декількох черг. Процесорний час буде даватися в першу чергу тим задачам, що стоять у самій привілейованій черзі. Якщо вона порожня, то диспетчер задач почне переглядати інші черги. Саме по такому алгоритмі діє диспетчер задач в операційних системах OS/2 і Windows NT.