Контекст I дескриптор процесу
Протягом існування процесу, його виконання може бути багаторазово перерване i продовжене. Для того, щоб відновити виконання процесу, необхідно відновити стан його операційного середовища. Стан операційного середовища відображається станом pericтpiв i програмного лічильника, режимом роботи процесора, показниками відкритих файлів, інформацією про незавершені операції введення-виведення, кодами помилок, виконуваних даним процесом системних викликів . Цю інформацію називають контекстом процессу.
Крім цього, операційній системі, для реалізації планування процесів, потрібна додаткова інформація; ідентифікатор процесу, стан процесу, дані про cтупінь привілейованості процесу, місце перебування кодового сегмента й інша інформація. У деяких ОС (наприклад, в ОС UNIX) таку інформацію ( що використовують ОС для планування процесів) називають дескриптором процесу.
Дескриптор процесу, в порівнянні з контекстом, містить більш оперативну інформацію, що легко доступна підсистемі планування процесів. Контекст процесу містить менш актуальну інформацію i використовується операційною системою тільки після того, як прийняте рішення про поновлення перерваного процесу.
Черги процесів є дескрипторами окремих процесів, що об'єднані в списки. Таким чином, кожен дескриптор, крім всього іншого, містить, принаймні, один показник на інший дескриптор, що сусідить із ним у черзі. Така організація черг дозволяє легко їx переупорядковувати, включати i виключати процеси, переводити процеси з одного стану в інший.
Програмний код тільки тоді починає виконуватися, коли для нього операційна система буде створює процес. Створити процес - це значить:
1. створити інформаційні структури, що описують даний процес, тобто його дескриптор i контекст;
2. включити дескриптор нового процесу в чергу готових процесів;
3. завантажити кодовий сегмент процесу в оперативну пам'ять чи в область свопінгу.
Алгоритми планування процесів
Планування процесів містить у coбi рішення наступних завдань:
1. визначення моменту часу, з метою зміни виконуваного процесу;
2. вибір процесу на виконання з черги готових процесів;
3. переключения контекстів "старого" i "нового" процесів.
Перші два завдання вирішують програмні засоби, а останні в значній мірі,- апаратно.
Існує безліч різних алгоритмів планування процесів, по-різному вирішуваних у перерахованих вище завданнях, що переслідують piзні цілі i забезпечують різну якість мультипрограмування. Серед цих алгоритмів розглянемо докладніше дві їх групи, що часто зустрічаються: алгоритми, засновані на квантуванні i алгоритми, засновані на пріоритетах.
Відповідно до aлгоритмів, заснованих на квантуванні, зміна активного процесу відбувається, якщо:
процес завершився i залишив систему;
наявна помилка;
процес перейшов у стан ЧЕКАННЯ;
вичерпано квант процесорного часу, відведений даному процесу.
Процес, що вичерпав свій квант, переводиться в стан ГОТОВНІСТЬ i очікує, коли йому буде наданий новий квант процесорного часу, а на виконання, відповідно до визначеного правила вибирається новий процес з черги готових. Таким чином, жоден процес не займає процесор надовго. Тому квантування широко використовують у системах поділу часу. Графа станів процесу, зображена на мапюнку 2.1., відповідає алгоритму планування, заснованому на квантуванні.
Кванти, виділені процесом, можуть бути однаковими для всіх процесів. Кванти, виділені одному процесові, є фіксованої величини.Вони можуть змінюватися в piзнi періоди життя процесу. Процеси, що не повністю використали виділений їм квант (наприклад, через відхід на виконання операцій виводу введення-виведення), можуть одержати, чи не одержати, компенсації у виді привілеїв при наступному обслуговуванні. По-різному може бути організована черга готових процесів.Наприклад, циклічно, за правилом "перший прийшов - перший обслужився" (FIFO) чи за правилом "останній прийшов - перший обслужився" (LIFO).
Інша група алгоритмів використовує поняття "пріоритет" процесу. Пріоритет - це число, що характеризує ступінь привілейованості процесу при використанні ресурсів обчислювальної машини, зокрема, процесорного часу: чим вище пріоритет, тим вище привілей.
Пріоритет може виражатися цілими чи дробовими, позитивним чи негативним значениям. Чим вищий привілей процесу, тим менше часу він буде в чергах. Пріоритет може призначатися директивно адміністратором системи, в залежності від важливості роботи чи внесеної плати, або ж обчислюватися самою ОС за визначеними правилами. Він може залишатися фіксованим протягом усього життя процесу або змінюватися в часі, відповідно до якогось закону. Уцьому випадку пріоритети називають динамічними. Існує два різновиди пріоритетних алгоритмів: алгоритми, що використовують відносні пріоритети, i алгоритми, що використовують абсолютні пріоритети.
В обох випадках вибір процесу на виконання, з черги вже готових, здійснюється однаково: вибирається процес, що має найвищий пріоритет. По-різному вирішується проблема визначення моменту зміни активного процесу. У системах із відносними пріоритетами, активний процес виконується доти, поки він сам не залишить процесор, перейшовши в стан ЧЕКАННЯ (чи ж закрадеться помилка або ж процес завершиться). У системах з абсолютними пріоритетами виконання активного процесу, він переривається ще при одній умові: якщо в черзі готових процесів з'явився процес, пріоритет якого вище пріоритету активного процесу. У цьому випадку перерваний процес переходить у стан готовності. На малюнку 2.2 зображені графи станів процесу для алгоритмів із відносними (a) i абсолютними (б) пріоритетами.
Мал. 2.2. Графи станів процесів у системах (а) із відносними пріоритетами; (б )з абсолютними пріоритетами.
У багатьох операційних системах алгоритми планування побудовані з використанням як квантування, так i пріоритетів. Наприклад, в основі планування лежить квантування, але величина кванта чи порядок вибору процесу з черги вже готових визначається пріоритетами процесів, що витісняють або не витісняють алгоритми планування.
Існує два основних типи процедур планування процесів: що витісняють (preemptive) i не витісняють (non-preemptive).
Non-preemptive multitasking - не витісняє багатозадачність - це cпociб планування процесів, при якому активний процес виконується доти, поки він сам, за власною ініціативою, не віддасть керування планувальнику операційної системи для того, щоб той вибрав з черги інший, готовий до виконання процес.
Preemptive multitasking (витісняє багатозадачність) - це cnociб, при якому рішення про переключення процесора з виконання одного процесу на виконання іншого приймається планувальником операційної системи, а не самою активною задачею.
Поняття preemptive i non-preemptive іноді утотожнюють із поняттями пріоритетних i безпріоритетних дисциплін, що зовсім невірно, а також з поняттями абсолютних i відносних пріоритетів, що частково неправильно. Що витісняє i не витісняє багатозадачність - це ширше поняття, ніж типи пріоритетності. Пріоритети задач можуть як застосовувати, так i не застосовувати. Так, у випадку використання пріоритетів, дисципліна відносних пріоритетів може належати до класу систем, що не витісняють багатозадачність, а дисципліна абсолютних пріоритетів - до класу систем, що витісняють багатозадачність. Безпріоритетна ж дисципліна планування, заснована на виділенні рівних квант часу для вcix задач, належить до алгоритмів, що витісняють.
Основною різницею між preemptive i non-preemptive варіантами багатозадачності є ступінь централізації механізму планування задач. При витісненні багатозадачності, механізм планування задач цілком зосереджений в операційній системі i програміст пише свій додаток, не турбуючись про те, що він буде виконуватися паралельно з іншими задачами. При цьому, операційа система виконує наступні функції: визначає момент зняття з виконання активної задачі, запам'ятовує її контекст, вибирає з черги готових задач наступну i запускає її на виконання, завантажуючи її контекст.
При невитісненні багатозадачності, механізм планування розподіляється між системою i прикладними програмами. Прикладна програма, одержавши керування від операційної системи, сама визначає момент завершення своєї чергової ітерації i передає керування ОС, за допомогою будь-якого системного виклику, а ОС формує черги задач i вибирає, відповідно до будь-якого алгоритму (наприклад, з урахуванням пріоритетів), наступну задачу на виконання. Такий механізм створює проблеми як для користувачів, так i для розроблювачів.
Для користувачів це означає, що керування системою губиться на довільний період часу, що визначається додатком (а не користувачем). Якщо додаток витрачає занадто багато часу на виконання будь-якої роботи, наприклад, на форматування диска, користувач не може переключитися з цієї задачі на іншу. Наприклад, на текстовий редактор, у той час як форматування продовжувалося б у фоновому режимі. Ця ситуація небажана, тому що користувачі звичайно, не хочуть довго чекати, поки машина завершить виконувати свою задачу.
Тому розроблювачі додатків для non-preemptive операційного середовища, покладаючи на себе функції планувальника, повинні створювати додатки так, щоб вони виконували свої задачі невеликими частинами. Наприклад, програма форматування може відформатувати одну доріжку дискети і повернути керування системі. Після виконання iнших задач, система поверне керування програмі форматування, вона відформатувала наступну доріжку. Подібний метод поділу часу між задачами “працює”, але він істотно затрудняє розробку програм i висуває підвищені вимоги до кваліфікації програміста. Програміст повинен забезпечити "дружнє" відношення своєї програми до іншої виконуваної одночасно з нею, досить часто віддаючи їй керування. Проявом “недружності” додатку є його зависання, що призводить до загального краху системи. У системах, що витісняють багатозадачність, такої ситуації, як правило, небуває.
Однак розподіл функцій планувальника між системою i додатками, завжди є недоліком, хоча, за певних умов, може бути i перевагою, оскільки дає можливість розроблювачу додатків самому проектувати алгоритм планування, найбільш придатний для даного фіксованого набору задач. У цьому випадку розроблювач сам визначає у npoгpaмi час віддачі керування, при цьому неможливі нераціональні переривання програм у "незручні” для них моменти часу. Kpiм цього, легко вирішуються проблеми використання даних: задача під час кожної ітерації використовує їх монопольно й упевнено, що не дозволяє нікому протягом цього періоду змінити ці дані. Істотною перевагою non-preemptive систем є висока швидкість переключення з задачі на задачу.
Прикладом ефективного використання, що не витісняє багатозадачності, є файл-сервер NetWare, де, у значній мipi, завдяки цьому, досягнута висока швидкість виконання файлових операцій. Менш вдалим є використання, що не витісняє багтозадачності з операційного середовища Windows 3.x.
Однак, майже всі сучасні операційні системи, орієнтовані на високопродуктивне виконання додатків (UNIX, Windows NT, OS/2 VAX/VMS), спрямовані на витіснена багатозадачності. Останнім часом, дійшла черга i до ОС класу настільних систем, наприклад, OS/2 Warp i Windows 95. Можливо, в зв'язку з цим, ОС, що витісняє багатозадачність, часто називають щирою багатозадачністю.
Засоби синхронізації i взаємодії процесів. Проблема синхронізації. Процесам часто потрібно взаємодіяти один з одним, наприклад, один процес може передавати дані іншому процесові, чи кілька процесів можуть обробляти дані із загального файлу. В ycix цих випадках виникає проблема синхронізації процесів, що може спричиняти припинення й активізацію процесів, організацією черг, блокування i звільнення pecypciв.
Мал. 2.3. Приклад необхідності синхронізації
Недооцінювання питаньми синхронізації процесів, що виконуються в режимі мультипрограмування, може привести до їх неправильної роботи чи, навіть, до краху системи. Розглянемо, як приклад (малюнок 2.3), програму печатки файлів (принт-сервер). Ця програма друкує по черзі yci файли, імена яких, послідовно, за порядком надходження, записують у спеціальний загальнодоступний файл "замовлень" iншi програми. Змінна NEXT, що доступна процесам-клієнтам, містить номер першої вільної, для запису iмeнi файлу, позиції файлу "замовлень". Процеси-клієнти читають цю змiннy, записують у відповідну позицію файлу "замовлень" ім'я свого файлу i нарощують значения NEXT на одиницю. Уявімо, що в деякий момент, процес R вирішив роздрукувати свій файл. З цією метою він прочитав значення перемінної NEXT, припустимо - 4. Процес запам'ятав це значення, але помістити iм'я файлу не встиг, тому що його виконання було перервано (наприклад, унаслідок вичерпання кванта). Черговий процес S, що бажає роздрукувати файл, прочитав те ж саме значення перемінної NEXT, помістив у четверту позицю ім'я свого файлу i наростив значення перемінної на одиницю. Коли чергу керування буде передано процесу R, то він, продовжуючи своє виконання, у повній відповідності зi значенням поточно вільної позиції, отриманим під час попередньої ітерації, запише ім'я файлу також у позицію 4, поверх iмeнi файлу процесу S.
Таким чином, процес S ніколи не побачить свій файл роздрукованим. Складність проблеми синхронізації полягає в нерегулярності виникаючих ситуацій(можна уявити й інший розвиток подій): загублені файли декількох процесів, навпроти, не був загублений жоден файл. У даному випадку ycе визначається взаємними швидкостями процесів i моментами їхнього переривання. Тому налагодження взаємодіючих процесів є складною задачею. Ситуації подібні до тiєї, коли два чи більше процеси обробляють поділювані дані, i кінцевий результат залежить від співвідношення швидкостей процесів, називаються гонками.