2.1.5. Стани процесів

Незважаючи на те що процес є незалежним об'єктом зі своїм

лічильником команд, регістрами, стеком, відкритими файлами, аварійними сигналами

та іншими атрибутами внутрішнього стану, існує необхідність його

взаємодії і синхронізації з іншими процесами. Наприклад, вихідні

дані одного процесу можуть служити вхідними даними для іншого

процесу. В цьому випадку необхідно забезпечити передачу даних між процесами.

Наприклад:

cat chapterl chapter2 chapter3 I grep tree

У цій команді оболонки перший процес cat об'єднує і роздруковує три

файлу. Другий процес grep відбирає всі рядки, що містять слово tree. В

Залежно від відносних швидкостей процесів (швидкості залежать від

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

кожному процесу) може вийти, що процес grep вже готовий до запуску, але

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

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

очікуваних процесом). Також можлива ситуація, коли активний і працездатний

процес зупиняється, тому що операційна система вирішила надати

на час процесор іншому процесу. Ці ситуації принципово різні.

У першому випадку призупинення виконання є внутрішньою проблемою

(Наприклад, неможливо обробити командний рядок користувача до того, як

вона введена). У другому випадку проблема є технічною (нестача про-

процесорів для кожного процесу). На рис. 2.2 представлена ​​діаграма станів,

показує три можливі стани процесу:

1. Виконання (процес використовує процесор).

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

іншому процесу).

3. Блокування (процес не може бути запущений перш, ніж відбудеться деяке

зовнішня подія).

Рис. 2.2. Процес може перебувати в стані виконання, готовності або блокування.

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

Як показано на малюнку, між цими трьома станами допустимі чотири

переходу. Перехід 1 відбувається, коли процес виявляє, що продовження

роботи неможливо. У деяких системах процес має виконати -

системний запит, наприклад block або pause, щоб опинитися в стані

блокування. В інших системах, наприклад в MINIX 3, процес автоматично

блокується, якщо при зчитуванні з каналу або спеціального файлу (припустимо,

терміналу) вхідні дані не виявлені. Переходи 2 і 3 викликаються частиною операційної системи, званої планувальником процесів, так що самі процеси навіть не знають про існування цих переходів. Перехід 2 відбувається, коли планувальник вирішує, що пора

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

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

Модель процесів спрощує уявлення про внутрішній поведінці системи.

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

дій залежить від пріоритету поточного процесу по відношенню до пріоритету

дискового драйвера. Проте важливіше тут те, що замість переривань ми

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

терміналу та т. п., блокуються на час очікування подій. Коли подія відбувається

відбувається (інформація зчитується з диска або клавіатури), блокування знімається,

після чого процес може бути запущений.

Розглянутий підхід описується моделлю, представленої на рис. 2.3.

Нижній рівень операційної системи - це планувальник, вище нього - все

безліч процесів. За обробку переривань і деталі, пов'язані із зупинкою

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

впорядкована у вигляді набору процесів. Модель, зображена на малюнку, використовується в операційній системі MINIX 3. Зрозуміло, нижній рівень складається не тільки з планувальника: він також забезпечує обробку переривань і взаємодія між процесами. Проте представлена ​​модель «у першому наближенні »адекватно демонструє основну структуру.