Модель віртуальних комунікаційних портів

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

· можливість одноманітних операцій із засобами взаємодії і з файлами;

• можливість доступу до видалених засобів як до видалених файлів;

· можливість використання єдиних засобів контролю доступу для файлової системи і для комунікацій.

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

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

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

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

Іменований порт має зовнішнє ім'я. Системний виклик відкриття іменованого порту вимагає вказівки цього імені як параметр виклику. Користувачі-розробники взаємодіючих процесів заздалегідь домовляються про використовувані імена портів. Система іменування портів і відкриття іменованих портів аналогічна файловій системі. Імена засобів взаємодії формуються по угодах іменування файлів і можуть виглядати, як імена файлів, розташованих в спеціальних каталогах, наприклад: каталог \shrmem - для загальних областей пам'яті, каталог \sem - для системних семафорів \pipe - для каналів \queues - для черг.

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

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