Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
всі білети.doc
Скачиваний:
1
Добавлен:
01.05.2025
Размер:
696 Кб
Скачать
☆

Міжпроцесова взаємодія на основі інтерфейсу файлової системи. Поіменовані канали

Поіменовані канали POSIX [24, 37] є однобічним засобом передавання даних. Це означає, що якщо один процес записує дані в канал, то інший із цього каналу мо­ же тільки читати, причому читання даних відбувається в порядку їхнього запису­ вання за принципом FIFO. Поіменовані канали відображені спеціальними FIFO-файлами у файловій систе­ мі UNIX. За іменем такого файла до поіменованого каналу може підключитися будь-який процес у системі, у якого є права читання з цього файла. Після цього всі дані, передані в канал, надходитимуть цьому процесу, поки канал не буде закрито. Для створення FIFO-файла у POSIX передбачена функція mkfifoO: linclude <sys/types.h> #іnсlude <sys/stat.h> int mkfifo (const char *pathname, mode_t mode); приклад: mkfifo ("адреса до файла". 0644);0664-режим поіменовані канали Win32 реалізують дво­ бічний обмін повідомленнями і не використовують прямо файли на файловій системі. Однак їхнє використання ґрунтується на схожих принципах. Імена таких каналів створюють за такою схемою: \\ім'я_машини\ріре\ім'я_каналу. Для доступу до каналу на локальному комп'ютері замість імені машини можна використовувати символ «.»: \\.\ріре\ім'я_каналу. Такі імена називають UNC-іме- нами (Universal Naming Convention - універсальна угода з імен); про них докладно йтиметься в розділі 16. Для створення екземпляра каналу на сервері використовують функцію СreateNamedPipeO: Для очікування клієнтського з'єднання необхідно виконати функцію Connect- NamedPi ре(): ConnectNamedPipe(ph. NULL); Як тільки клієнт підключиться до цього каналу, очікування буде завершене, і можна читати з каналу або записувати в канал за допомогою ReadFi1е() і WriteFileO. Після завершення обміну даними сервер закриває з'єднання, викликавши функцію DisconnectNamedPipeO

ЕКЗАМЕНАЦІЙНИЙ БІЛЕТ № 8

Архітектура операційних систем. Реалізація архітектури операційних систем. Багаторівневі системи.

Компоненти багаторівневих ОС утворюють ієрархію рівнів (шарів, layers), кожен з яких спирається на функції попереднього рівня. Найнижчий рівень безпосеред­ ньо взаємодіє з апаратним забезпеченням, на найвищому рівні реалізуються сис­ темні виклики. У традиційних багаторівневих ОС передача керування з верхнього рівня на нижній реалізується як системний виклик. Верхній рівень повинен мати права на виконання цього виклику, перевірка цих прав виконується за підтримки апарат­ ного забезпечення. Прикладом такої системи є ОС Multics, розроблена в 60-ті роки. Практичне застосування цього підходу сьогодні обмежене через низьку продуктивність. Рівні можуть виділятися й у монолітному ядрі; у такому разі вони підтриму­ ються програмно і спричиняють спрощення реалізації системи. У монолітному ядрі визначають рівні, перелічені нижче.

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

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

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

Інтерфейс системних викликів, який служить для реалізації зв'язку із систем­ ним і прикладним програмним забезпеченням. Розмежування базових засобів ядра і менеджерів ресурсів відповідає відо­ кремленню механізмів від політики в архітектурі системи. Базові засоби ядра визначають механізми функціонування системи, менеджери ресурсів реалізують політику.