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

Процес із пасивного стану може перейти в стан готовності в наступних випадках:

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

при виборі з черги планувальником (характерно для ОС, які працюють в пакетному режимі);

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

по перериванню від зовнішнього ініціативного пристрою;

при настанні запланованого часу запуску програми.

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

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

Із стану виконання процес може вийти по одній із наступних причин:

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

процес переводиться супервізором операційної системи в стан готовності до виконання в зв’язку з появою більш пріоритетної задачі або в зв’язку із закінченням наданого йому кванту часу;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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