НОУ ІНТУІТ, Лекція, Управління процесами

Взаємодія процесів

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

З кожним процесом пов'язані три незалежні потоки даних: стандартне введення (stdin), стандартне виведення (stdout) і стандартний потік повідомлень про помилки (stderr). За замовчуванням всі три потоки пов'язані з тим терміналом, з якого запущено процес (стандартне введення – з клавіатури, виведення даних та помилок – на екран). Стандартне введення також називають вхідним потоком, а стандартне виведення – вихідним.

Кожному з цих потоків співвіднесені внутрішні дескриптори файлів: вхідному потоку – 0, вихідному потоку – 1, потоку повідомлень про помилки – 2. Внутрішній дескриптор файлу існує лише в межах процесу, з яким він пов'язаний. Внутрішні дескриптори у різних процесах мають однакові номери, але це фізично різні внутрішні дескриптори, і кожен процес має власні внутрішні дескриптори.

Перенаправлення потоків

Потік даних, пов'язаний з процесом, може бути перенаправлений у файл або інший потік даних. Наприклад, якщо потрібно, щоб програма find видала список імен файлів у файл names, а не термінал, слід виконати команду

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

Для додавання виведення програми в кінець файлу слід використовувати конструкцію "дві праві кутові дужки" >>

У цьому випадку файл names будестворений, якщо він не існує, а якщо існує, вихідний потік програми find додасться до кінця файлу .

Можна перенаправити текст із файлу у вхідний потік.

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

Це дає можливість перенаправити введення в процес не з файлу, а прямо з командного рядка (або скриптового тіла):

Вказівка у тексті значків Таблиця 9.2. Сигнали POSIX 1.1

Крім команди pkill системний адміністратор може знайти зручну команду pgrep, яка замінює конструкцію

У Solaris для отримання того ж результату можна ввести більш коротку команду

Канали та сокети

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

Канал – це послідовність байт, використовувана як односпрямований потік вводу/виводу.

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

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

Для кожного процесуядро зберігає таблицю внутрішніх дескрипторів. По-англійськи ця таблиця називається "descriptor table", і щоб не плутати її з таблицею дескрипторів у файловій системі, ми називаємо внутрішню таблицю дескрипторів, що відноситься до конкретного процесу, "таблицею внутрішніх дескрипторів". Слово "внутрішніх" підкреслює те, що ці дескриптори існують лише в межах процесу, який ними користується для звернення до файлів. Ця таблиця успадковується від батьківського процесу, тому разом із нею успадковується і доступом до об'єктів, куди посилаються дескриптори (файлам , каналам, сокетам).

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

Семафори – це механізм, який прийнято використовуватиме контролю доступу кількох процесів одного ресурсу. Є кілька реалізацій програмного інтерфейсу (API), пов'язаного з семафорами:

варіант System V IPC (inter-process communication);
BSD;
POSIX 1003.1b.

Семафор насправді – це змінна, залежно від значення якої доступом до тому чи іншого ресурсу дозволяється чи блокується до його звільнення. Семафори широко використовуються в Oracle. Щоб налаштувати підсистему семафорів у Solaris до версії 9 включно (забезпечити достатню кількість семафорів у ядрі), може знадобитися внести зміни до файлу конфігурації ядра/etc/system. Щоб дізнатися, які параметри потрібні саме вашому програмному забезпеченню під Solaris , зверніться до посібника з цього програмного забезпечення.

Для Oracle8i у Oracle8i Installation Guide Release 3 рекомендуються наступні початкові значення параметрів:

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

Подивитися поточні значення параметрів семафорів у Solaris до версії 9 можна було включно за командою

Однак, починаючи з версії Solaris 10, для цього слід застосовувати команду prctl, про використання якої більше розповідається в лекції 5 курсу "Системне адміністрування ОС Solaris 10".

Подивитися поточні набори семафорів у Solaris можна за командою

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

semsetID тут означає ідентифікатор набору семафорів.