4.6.5. Засоби взаємодії процесів в стандарті posix

Десятиліття успішного використання UNIX виявили, тим не менше, ряд недоліків у вихідній архітектурі цієї системи. Одним з найпомітніших прогалин була явна слабкість механізму синхронізації процесів, заснованого фактично лише на сигналах і на функції wait. На практиці в більшості реалізацій UNIX вводилися додаткові, більш зручні засоби взаємодії між процесами, однак виникала проблема несумісності таких засобів для різних версій UNIX. Різнобій був припинений на початку 90-х років з виробленням стандарту POSIX, який об'єднав все найкраще, що до того часу було запропоновано в різних версіях UNIX.

До засобів, які, згідно POSIX, повинна підтримувати будь-яка сучасна реалізація UNIX, належать, зокрема:

· Сигнали;

· Безіменні і іменовані канали;

· Черги повідомлень;

· Семафори;

· Спільно використовувані (розділяються) області пам'яті.

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

4.6.6. Планування процесів

4.6.6.1. Стану процесів в unix

UNIX є багатозадачного системою з витісняючої пріоритетною диспетчеризацією.

Діаграма основних станів процесу, показана на рис. 4-1, в разі UNIX може бути уточнена так, як показано на рис. 4-2.

Рис. 4‑17

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

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

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

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

Зі сказаного можна зробити два важливих висновки.

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

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

У діаграмі на рис. 4-2 не враховано ще деякі стани, в яких може перебувати процес в UNIX. До їх числа відносяться стан старту (процес тільки що створений, але ще не готовий до виконання), стан зомбі (див. п. 4.6.1) і стан призупинення, в яке переходить процес, який отримав сигнал SIGSTOP (див. п. 4.6. 4).