Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

spz / spz

.pdf
Скачиваний:
29
Добавлен:
23.02.2016
Размер:
5.16 Mб
Скачать

7

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

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

Як ми бачимо з мал, тут немає безпосереднього повернення в перервану раніше програму безпосередньо із самої підпрограми обробки переривання. Для прямого безпосереднього повернення достатньо адресу повернення зберегти в стеці, що і робить апаратура процесора. При цьому стек легко забезпечує можливість повернення у випадку вкладених переривань, оскільки він завжди реалізує дисципліну LCFS (last come – first served).

Переривання

Виконувана супервізор переривань

програма

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

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

8

Виконання коду підпрограми обробки переривання

Ця підпрограма вже не піклується про збереження контексту перерваного процесу

Диспетчер задач

Вибір готової до виконання задачі (на основі прийнятої дисципліни обслуговування)

Відновлення контексту перерваної раніше програми,

установка попереднього режиму роботи системи переривань та передача керування цій задачі

Рис. 1.6. Обробка переривання за участю супервізорів ОС

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

Системне програмне забезпечення. І.Яковлєва.

1

Планування та диспетчеризація процесів та задач

1.Функції ОС, пов’язані з керуванням задач.

2.Організація черг процесів та ресурсів.

3.Стратегії планування.

4.Якість диспетчеризації та гарантії обслуговування.

5.Критерії порівняння алгоритмів диспетчеризації.

6.Причини зменшення продуктивності системи.

ОС виконує основні наступні функції, пов’язані з керуванням задач:

-Створення та знищення задач;

-Планування процесів та диспетчеризація задач

-Синхронізація задач, забезпечення їх засобами комунікації.

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

черг процесів та ресурсів.

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

В наш час найбільш актуальною задачею є задачі динамічного (або короткострокового) планування, тобто поточного найбільш ефективного розподілення ресурсів, яке виникає практично на кожній події. Задачі

динамічного планування називають диспетчеризацією.

Короткостроковий планувальник може запускатися кожні 30 –100 мс.

Стратегії планування

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

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

-Надавати перевагу більш коротким процесам;

-Надавати усім користувачам (процесам) однакові послуги, в тому числі о однаковий час очікування.

Якість диспетчеризації і гарантії обслуговування

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

Системне програмне забезпечення. І.Яковлєва.

2

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

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

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

Гарантувати обслуговування можна наступними трьома способами:

1.виділяти мінімальну частку процесорного часу деякому класу процесів, якщо принаймні один з них готовий до виконання. Наприклад, можна відводити 20 % від кожних 10 мс процесам реального часу, 40 % від кожних 2 з - інтерактивним процесам і 10 % від кожних 5 хв — пакетним (фоновим) процесам;

2.виділяти мінімальну частку процесорного часу деякому конкретному процесу, якщо він готовий до виконання;

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

Для порівняння алгоритмів диспетчеризації звичайно

використовуються наступні критерії:

-Використання (завантаження) центрального процесора (CPU utilization). У більшості персональних систем середнє завантаження процесора не перевищує 2-3 %, доходячи в моменти виконання складних обчислень і до 100 %. У реальних системах, де комп'ютери виконують дуже багато роботи, наприклад, у серверах, завантаження процесора коливається в межах 15-40 % для легко завантаженого процесора і до 90-100 % — для сильно завантаженого процесора.

-Пропускна здатність (CPU throughput). Пропускна здатність процесора може вимірятися кількістю процесів, що виконуються в одиницю часу.

-Час обороту (turnaround time). Для деяких процесів важливим критерієм є повний час виконання, тобто інтервал від моменту появи процесу у

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

Системне програмне забезпечення. І.Яковлєва.

3

-Час чекання (waiting time). Під часом чекання розуміється сумарний час перебування процесу в черзі готових процесів.

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

Правильне планування процесів сильно впливає на продуктивність усієї системи. Можна виділити наступні головні причини, що приводять до зменшення продуктивності системи:

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

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

Системне програмне забезпечення

І.Яковлєва

1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Системне програмне забезпечення

І.Яковлєва

2

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

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

Безпріоритетні

 

 

Пріоритетні

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Лінійні

 

Циклічні

 

 

 

З фіксованим

пріоритетом

 

З динамічним

пріоритетом

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

В порядку черги

 

Випадковий вибір процесу

 

Циклічний алгоритм

 

Багатопріоритетний циклічний

 

З відносним пріоритетом

 

З абсолютним пріоритетом

 

Адаптивне обслуговування

 

Пріоритет залежить від часу очікування

 

Пріоритет залежить від часу обслуговування

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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

Системне програмне забезпечення

І.Яковлєва

3

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

Процесор

Блокування

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

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

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

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

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

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

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

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

висока швидкість виконання

файлових

операцій. Менш

вдалим

виявилося використання

не

витісняючої

багатозадачності

в ОС

Windows 3.х.

 

 

 

 

У більшості сучасних ОС

для могутніх обчислювальних систем, а

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

Але

розглянута дисципліна FCFS відноситься

до не

витісняючих.

 

 

До переваг цієї дисципліни, по-перше, можна віднести

простоту

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

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

Системне програмне забезпечення

І.Яковлєва

4

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

SJN і SRT.

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

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

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

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

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

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

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

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

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

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

Системне програмне забезпечення

І.Яковлєва

5

Дисципліна обслуговування 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.

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

Тут вы можете оставить комментарий к выбранному абзацу или сообщить об ошибке.

Оставленные комментарии видны всем.

Соседние файлы в папке spz