Семафори

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

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

Виконання операцій над семафором може забезпечуватися системним викликом вигляду:

flag = semaphoreOp(semaphorId, opCode, waitOption);

де semaphorId - маніпулятор семафора, opCode - код операції, waitOption - опція очікування, flag - значення, що повертається, ознака успішного виконання операції або код помилки.

Крім основних для семафорів P- і V-операций, конкретні семафорні API ОС можуть включати розширені і сервісні функції, такі як безумовна установка семафора, установка семафора і очікування його очищення, очікування очищення семафора. При виконанні системних викликів - аналогів P-операции, як правило, є можливість задати опцію очікування - блокувати процес, якщо виконання P-операции неможливе, або завершити системний виклик з ознакою помилки.

У багато сучасних ОС разом з семафорами "в чистому виді" API представляє ті ж семафори і у вигляді "прикладних" об'єктів - об'єктів взаємного виключення і подій. Хоча зміст цих об'єктів одне і те ж - семафор, ОС відносно цих об'єктів представляє для прикладних процесів специфічну семантику API, відповідну завданням взаємного виключення і синхронізації.

Всі сучасні ОС надають прикладному процесу можливість працювати з "масивами семафорів", тобто, задавати список семафорів і виконувати операцію над всім списком, наприклад, чекати очищення будь-якого семафора в заданому списку. Найбільш розвинений цей засіб в ОС Unix, де є можливість виконувати за один системний виклик semop (аналог нашого semaphoreOp) відразу декількох різних операцій над декількома семафорами, причому весь список операцій виконується, як одна транзакція. Неіменовані семафори зазвичай використовуються як засіб взаємного виключення і синхронізації роботи ниток одного процесу.

Програмні канали

Програмний канал по-англійськи називається pipe (труба), і це вельми вдала назва. Канал дійсно можна представити як трубопровід пневматичної пошти, прокладений між двома процесами, як показано на рис.9.1. По цьому трубопроводу дані передаються від одного процесу до іншого. Як і трубопровід, програмний канал однонаправлений (хоча, наприклад, в Unix одним системним викликом створюються відразу два різноспрямовані канали). Як і трубопровід, програмний канал має власну ємкість: дані записані в канал, не обов'язково повинні негайно вибиратися не протилежному його кінці, але можуть накопичуватися в каналі, поки це дозволяє його ємкість. Як і трубопровід, канал працює по дисципліні FIFO: перший увійшов - перший вийшов.

Ріс.9.1. Програмні канали

Зі всіх засобів взаємодії між процесами канали (pipe) краще всього вписуються в модель віртуальних комунікаційних портів. Канал для процесу практично аналогічний файлу. Спеціальні системні виклики типу createPipe, openPipe використовуються для створення каналу і діставання доступу до каналу, а для роботи з каналом використовуються ті ж виклики read і write, що і для файлів, і навіть закриття каналу виконується файловим системним викликом close. При створенні каналу для нього створюється дескриптор, як для відкритого файлу, що дозволяє працювати з ним далі, як з файлом. Канал, проте, є не зовнішніми даними, а областю пам'яті. Для каналу виділяється пам'ять в системній області, що може обмежувати ємкість каналу.

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

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

Іменовані канали є зручним засобом клієнт-серверних комунікацій. Іменовані канали в деяких ОС (наприклад, OS/2) істотно відрізняються від неіменованих. Іменовані канали орієнтовані в цих системах перш за все на взаємодію процесів в мережевому середовищі (або, точніше, для них прозоро, чи знаходяться обидва процеси на одному комп'ютері або в різних вузлах мережі). Такий канал двонаправлений, тобто, до нього можливі звернення і для читання, і для запису. Дані в каналі можуть передаватися як потоком байт, так і повідомленнями. У останньому випадку кожне повідомлення забезпечується заголовком, в якому указується його довжина. До одного кінця каналу постійно підключений процес, що його створив, - власник або сервер, до іншого кінця можуть підключатися різні процеси-клієнти, таким чином, обмін даними по іменованому каналу між процесами, жоден з яких не є власником каналу, неможливий. При створенні каналу (системний виклик createNamedPipe) указується максимально можливе число клієнтів, які можуть бути одночасно підключені до каналу (це число, втім, може і не обмежуватися). Коли власник створює канал, канал знаходиться в так званому відключеному стані. Системним викликом connectNamedPipe власник переводить канал в стан, що чекає. Тепер процеси-клієнти можуть підключатися до іншого кінця каналу за допомогою файлових системних викликів openNamedPipe. Канал, відкритий хоч би одним клієнтом, вважається підключеним, сервер і підключені клієнти можуть працювати з ним, використовуючи виклики файлового API. Клієнти відключаються від каналу викликом close, у розпорядженні власника є виклик disconnectNamedPipe - розриву каналу. Крім звичайних викликів файлового обміну, для роботи з іменованим каналом у складі API можуть бути спеціальні системні виклики, що забезпечують виконання складних транзакцій на іменованому каналі наприклад: transactNamedPipe - взаємний обмін даними (вивід і введення) за одну операцію, callNamedPipe - забезпечує також відкриття каналу, взаємний обмін, закриття каналу. Крім того, до іменованого каналу або до декількох іменованих каналів може бути підключений семафор, який скидається при зміні стану каналу (заповнений - не заповнений, порожній - не порожній).