47931

Основні поняття та визначення концепцій операційніх систем

Конспект

Информатика, кибернетика и программирование

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

Украинкский

2013-12-04

11.08 MB

10 чел.

Розділ1.  Основні поняття та визначення концепцій операційніх        систем.

(аудиторних-4/4г. , самостійних- 2/6г.)

       

Лекція №1.

Тема:  поняття, призначення та класифікація операційних ситем.

План:

  1.  Поняття операційної ситеми (Л1. ст.17).
  2.  Призначення операційної системи (Л1. ст.18).
  3.  Операційна система як розширена машина (Л1. ст.18-19).
  4.  Операційна система як розподілювач ресурсів (Л1. ст.19).
  5.  Історія розвитку операційних ситем (Л1. ст.21-22.)
  6.  Класифікація сучасних операційних систем (Л1. ст. 20-21).

1.

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

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

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

2.

 

Операційні системи забезпечують, по-перше, зручність використання комп'ютерної системи, по-друге, ефективність і надійність її роботи.

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

3.

За допомогою операційної системи у прикладного програміста (а через його програми і в користувача) має створюватися враження, що він працює з розширеною машиною

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

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

Інтерфейс

прикладного

програмування

Інтерфейс апаратного забезпечення

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

4.

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

Розрізняють два основні види розподілу ресурсів – просторовий і часовий. У разі просторового розподілу ресурс доступний декільком споживачам одночасно, при цьому кожен із них може користуватися частиною ресурсу (так розподіляється пам'ять). У разі часового розподілу система ставить споживачів у чергу і згідно з нею надає їм змогу користуватися всім ресурсом обмежений час (так розподіляється процесор в од-нопроцесорних системах).

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

5.

Перші операційні системи з'явилися в 50-ті роки і були системами пакетної обробки. Такі системи забезпечували послідовне виконання програм у пакетному режимі (без можливості взаємодії з користувачем). У певний момент часу в пам'яті могла перебувати тільки одна програма (системи були однозадачними), усі програми виконувалися на процесорі від початку до кінця. За такої ситуації ОС розглядали просто як набір стандартних служб, необхідних прикладним програмам і користувачам.

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

Підтримка багатозадачності потребувала реалізації в ОС засобів координації задач. Можна виділити три складові частини такої координації.

  1.  Захист критичних даних задачі від випадкового або навмисного доступу інших задач.

Забезпечення обміну даними між задачами.

  1.  Надання задачам справедливої частки ресурсів (пам'яті, процесора, дискового простору

тощо).

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

6.

Залежно від області  застосування ОС діляться на ОС великих ЕОМ (мейнфреймів), серверні ОС, персональні ОС, ОС реального часу, вбудовані ОС.

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

До наступної категорії можна віднести серверні ОС. Головна характеристика таких ОС - здатність обслуговувати велику кількість запитів користувачів до спільно використовуваних ресурсів. Важливу роль для них відіграє мережна підтримка. Є спеціалізовані серверні ОС, з яких виключені елементи, не пов'язані з виконанням їхніх основних функцій (наприклад, підтримка застосувань користувача). Нині для реалізації серверів частіше застосовують універсальні ОС (UNIX або системи лінії Windows ХР).

Наймасовіша категорія - персональні ОС. Деякі ОС цієї категорії розробляли з розрахунком на непрофесійного користувача (лінія Windows 95/98/Ме фірми Microsoft, які називають Consumer Windows), інші є спрощеними версіями універсальних ОС. Особлива увага в персональних ОС приділяється підтримці графічного інтерфейсу користувача і мультимедіа-технологій.

Виділяють також ОС реального часу. У такій системі кожна операція має бути гарантовано виконана в заданому часовому діапазоні. ОС реального часу можуть керувати польотом космічного корабля, технологічним процесом або демонстрацією відеороликів. Існують спеціалізовані ОС реального часу, такі як QNX  і VxWorks.

Ще однією категорією є вбудовані ОС. До них належать керуючі програми для різноманітних мікропроцесорних систем, які використовують у військовій техніці, системах побутової електроніки, смарт-картах та інших пристроях. До таких систем ставлять особливі вимоги: розміщення в малому обсязі пам'яті, підтримка спеціалізованих засобів введення-виведення, можливість прошивання в постійному запам'ятовувальному пристрої. Часто вбудовані ОС розробляються під конкретний пристрій; до універсальних систем належать Embedded Linux  і Windows СЕ.

Лекція №2.

Тема:  функціональні компоненти операційних систем.

План:

1.Функціональні компоненти ОС (Л1. ст.21).

2.Керування процесами й потоками (Л1. ст.21-22).

3.Керування пам`яттю (Л1. ст.22).

4.Керування введенням - виведенням (Л1. ст.22).

5.Керування файлами та файлові системи (Л1. ст.22 - 23.)

6.Мержні та розподілені системи (Л1. ст. 23).

7.Безпека даних (Л1. ст. 23).

8.Інтерфейс користувача (Л1. ст. 23 – 24).

 1.

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

Спосіб побудови системи зі складових частин та їхній взаємозв'язок визначає архітектура операційної системи.

2.

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

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

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

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

Сучасні ОС крім багатозадачності можуть підтримувати багатопотоковість (multithreading), яка передбачає в рамках процесу наявність кількох окремих послідовностей інструкцій (потоків, threads), які для користувача виконуються паралельно, подібно до самих процесів в ОС. На відміну від процесів потоки не забезпечують захисту ресурсів (наприклад, вони спільно використовують адресний простір свого процесу).

3.

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

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

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

4.

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

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

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

5.

Для користувачів ОС і прикладних програмістів дисковий простір надається у вигляді сукупності файлів, організованих у файлову систему.

Файл - це набір даних у файловій системі, доступ до якого здійснюється за іменем. Термін «файлова система» може вживатися для двох понять: принципу організації даних у вигляді файлів, які доступні користувачеві і конкретного набору структур даних (зазвичай відповідної частини диска - розділу), організованих відповідно до такого принципу, які користувачеві недоступні. У рамках ОС може бути реалізована одночасна підтримка декількох файлових систем.

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

6.

Мережні системи це сучасні операційні системи, які пристосовані до роботи в мережі. Їх називають ме-режними операційними системами . Засоби мережної підтримки дають ОС можливість:

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

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

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

Мережні ОС не приховують від користувача наявність мережі, мережна підтримка в них не визначає структуру системи, а збагачує її додатковими можливостями. Є також розподілені ОС, які дають змогу об'єднати ресурси декількох комп'ютерів у розподілену систему. Вона виглядає для користувача як один комп'ютер з декількома процесорами, що працюють паралельно. Розподілені та багатопроцесорні системи є двома основними категоріями ОС, які використовують декілька процесорів і мають багато спільного.

7.

Під безпекою даних в ОС розуміють забезпечення надійності системи (захист даних від втрати у разі збоїв) і захист даних від несанкціонованого доступу (випадкового чи навмисного).

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

8.

Розрізняють два типи засобів взаємодії користувача з ОС: командний інтерпретатор (shell) і графічний інтерфейс користувача (GUI).

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

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

Висновки до розділу 1.

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

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

 

Контрольні запитання та завдання

  1.  Які основні функції операційної системи? Чи немає між ними протиріч?
  2.  Наведіть кілька прикладів просторового і часового розподілу ресурсів комп'ютера. Від чого залежить вибір того чи іншого методу розподілу?
  3.  У чому полягає основна відмінність багатозадачних пакетних систем від систем з розподілом часу? Як можна в рамках однієї системи об'єднати можливості обох зазначених систем?
  4.  Чому більшість вбудованих систем розроблено як системи реального часу? Наведіть приклади вбудованих систем, для яких підтримка режиму реального часу не є обов'язковою.
  5.  Що спільного й у чому відмінності між мережною і розподіленою операційними системами? Яка з них складніша в реалізації і чому?

Розділ2.             Архітектура операційних систем.

(аудиторних-8/12г. , самостійних- 6/4г.)

       

Лекція №1.

Тема:  базові поняття архітектури операційних ситем.

План:

1.Механізми і політика в ОС. (Л1. ст.25-26).

2.Ядро ситеми та режими роботи процесора. (Л1. ст.26-27).

3.Системне програмне забезпечення (Л1. ст.27).

4.Монолітні ОС (Л1. ст.27).

5.Багаторівневі ОС (Л1. ст. 27-28)

6.Системи з мікроядром (Л1. ст.28-29.)

7.Концепція віртуальних машин (Л1. ст. 29-30).

1.

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

В ОС насамперед необхідно виділити набір фундаментальних можливостей, які надають її компоненти; ці базові можливості становлять механізм (mechanism). Механізми ОС можна використовувати по різному, отже спосіб використання механізму  визначає політику (policy) ОС. Таким чином, механізм показує, що реалізовано компонентом, а політика - як це можна використати.

Коли за реалізацію механізму і політики відповідають різні компоненти (механізм відокремлений від політики), спрощується розробка системи і підвищується її гнучкість. Компонентам, що реалізують механізм, не повинна бути доступна інформація про причини та цілі його застосування; усе, що потрібно від них, - це виконувати призначену їм роботу. Для таких компонентів використовують термін «вільні від політики» (policy-free). Компоненти, відповідальні за політику, мають оперувати вільними від неї компонентами як будівельними блоками, для них недоступна інформація про деталі реалізації механізму.

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

2.

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

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

Основною характерною ознакою ядра є те, що воно виконується у привілейованому режимі.  Особливості цього режиму полягають в тому, що для забезпечення ефективного керування ресурсами комп'ютера ОС повинна мати певні привілеї щодо прикладних програм. Треба, щоб прикладні програми не втручалися в роботу ОС, і водночас ОС повинна мати можливість втрутитися в роботу будь-якої програми, наприклад для перемикання процесора або розв'язання конфлікту в боротьбі за ресурси. Для реалізації таких привілеїв потрібна апаратна підтримка: процесор має підтримувати два режими роботи — привілейований (захищений режим, режим ядра, kernel mode) і режим користувача (user mode). У режимі користувача недопустимі команди, які є критичними для роботи системи (перемикання задач, звертання до пам'яті за заданими межами, доступ до пристроїв введення-виведення тощо).

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

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

3.

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

системні програми (утиліти), наприклад: командний інтерпретатор, програми резервного копіювання та відновлення даних, засоби діагностики й адміністрування;

системні бібліотеки, у яких реалізовані функції, що використовуються у застосуваннях користувача.

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

4.

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

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

5.

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

У традиційних багаторівневих ОС передача керування з верхнього рівня на нижній реалізується як системний виклик. Верхній рівень повинен мати права на виконання цього виклику, перевірка цих прав виконується за підтримки апаратного забезпечення. Прикладом такої системи є ОС Multics, розроблена в 60-ті роки. Практичне застосування цього підходу сьогодні обмежене через низьку продуктивність.

Рівні можуть виділятися і в монолітному ядрі; у такому разі вони підтримуються програмно і ведуть до  спрощення реалізації системи. У монолітном ядрі визначають рівні, перелічені нижче.

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

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

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

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

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

6.

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

Мікроядро здійснює зв'язок між компонентами системи і виконує базовий розподіл ресурсів. Щоб виконати системний виклик, процес (клієнтський процес, клієнт) звертається до мікроядра. Мікроядро посилає серверу запит, сервер виконує роботу і пересилає відповідь назад, а мікроядро переправляє його клієнтові (рис. 2.1). Клієнтами можуть бути не лише процеси користувача, а й інші модулі ОС.

Перевагами мікроядрового підходу є:

  •  невеликі розміри мікроядра, що спрощує його розробку й налагодження;
  •  висока надійність системи, внаслідок того що сервери працюють у режимі користувача і в них немає прямого доступу до апаратного забезпечення;
  •  більша гнучкість і розширюваність системи (непотрібні компоненти не займають місця в пам'яті, розширення функціональності системи зводиться до додавання в неї нового сервера);
  •  можливість адаптації до умов мережі (спосіб обміну даними між клієнтом і сервером не залежить від того, зв'язані вони мережею чи перебувають на одному комп'ютері).
  •  Головним недоліком мікроядрового підходу є зниження продуктивності. Замість двох перемикань режиму процесора у разі системного виклику відбувається чотири (два — під час обміну між клієнтом і мікроядром, два - між сервером та мікроядром).

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

7.

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

Уперше концепція віртуальних машин була реалізована в 70-ті роки в операційній системі VM фірми IBM. У СРСР варіант цієї системи (VM/370) був широко розповсюджений у 80-ті роки і мав назву Система віртуальних машин ЄС ЕОМ (СВМ ЄС). Ядро системи, яке називається монітором віртуальних машин (VM Monitor, МВМ), виконуєтьсяся на фізичній машині, безпосередньо взаємодіючи з її апаратним забезпеченням. Монітор (ситемна програма) забезпечує набір віртуальних машин (ВМ). Кожна ВМ є точною копією апаратного забезпечення, на ній може бути запущена будь-яка ОС, розроблена для цієї архітектури. Найчастіше на ВМ встановлювали спеціальну однокористувацьку ОС CMS (підсистема діалогової обробки, ПДО). На різних ВМ могли одночасно функціонувати різні ОС.

Коли програма, написана для ПДО, виконувала системний виклик, його перехоплювала копія ПДО, запущена на відповідній віртуальній машині. Потім ПДО виконувала відповідні апаратні інструкції, наприклад інструкції введення-виведення для читання диска. Ці інструкції перехоплював МВМ і перетворював їх на апаратні інструкції фізичної машини.

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

 Лекція №2.

Тема:  операційна система та її оточення.

План:

1.Взаємодія ОС і апаратного забезпечення (Л1. ст.30).

2.Засоби апаратної підтримки операційних систем (Л1. ст.30-32).

3.Апаратна незалежність і здатність до перенесення ОС (Л1. ст.32).

4.Взаємодія ОС і виконуваного програмного коду(Л1. ст.32).

5.Системні виклики та інтерфейс програмування застосувань (Л1. ст. 27-28)

6.Програмна сумісність (Л1. ст.34.)

1.

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

2.

Сучасні апаратні архітектури комп'ютерів забезпечують базові засоби підтримки операційних систем. До них належать: система переривань, привілейований режим процесора, засоби перемикання задач, підтримка керування пам'яттю (механізми трансляції адрес, захист пам'яті), системний таймер, захист пристроїв введення-виведення, базова система введення-виведення (BIOS). Розглянемо ці засоби докладніше.

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

Апаратне переривання - це спеціальний сигнал (запит переривання, IRQ), що передається процесору від апаратного пристрою.

До апаратних переривань належать:

  •  переривання введення-виведення, що надходять від контролера периферійного пристрою; наприклад, таке переривання генерує контролер клавіатури при натисканні на клавішу;
  •   переривання, пов'язані з апаратними або програмними помилками (такі переривання виникають, наприклад, у разі збою контролера диска, доступу до забороненої області пам'яті або ділення на нуль).

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

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

За встановлення оброблювачів переривань зазвичай відповідає ОС. Можна сказати, що сучасні ОС керовані перериваннями (interrupt-driven), бо, якщо ОС не зайнята виконанням якої-небудь задачі, вона очікує на переривання, яке й залучає її до роботи.

Для реалізації привілейованого режиму процесора в одному з його регістрів передбачено спеціальний біт (біт режиму), котрий показує, у якому режимі перебуває процесор. У разі програмного або апаратного переривання процесор автоматично перемикається у привілейований режим, і саме тому ядро ОС (яке складається з оброблювачів переривань) завжди отримує керування в цьому режимі. За будь-якої спроби безпосередньо виконати привілейовану інструкцію в режимі користувача відбувається апаратне переривання.

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

Механізм трансляції адрес забезпечує перетворення адрес пам'яті, з якими працює програма, в адреси фізичної пам'яті комп'ютера. Апаратне забезпечення генерує фізичну адресу, використовуючи спеціальні таблиці трансляції.

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

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

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

Базова система введення-виведення (BIOS) — службовий програмний код, що зберігається в постійному запам'ятовувальному пристрої і призначений для ізоляції ОС від конкретного апаратного забезпечення. Зазначимо, що засоби BIOS не завжди дають змогу використати всі можливості архітектури: наприклад, процедури BIOS для архітектури ІА-32 не працюють у захищеному режимі. Тому сучасні ОС використовують їх тільки для початкового завантаження системи.

3.

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

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

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

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

  •  Більша частина коду операційної системи має бути написана мовою високого рівня (звичайно для цього використовують мови С і C++, компілятори яких розроблені для більшості архітектур). Використання мови асемблера допустиме лише тоді, коли продуктивність компонента є критичною для системи.
  •  Код, що залежить від апаратного забезпечення (рівень абстрагування від устаткування) має бути відокремлений від іншої частини системи так, щоб у разі переходу на іншу архітектуру потрібно було переписувати тільки цей рівень.

4.

У роботі в режимі користувача часто необхідне виконання дій, реалізованих у ядрі ОС (наприклад, під час запису на диск із прикладної програми). Для цього треба забезпечити взаємодію коду режиму користувача та ОС. Програмною основою такої взаємодії  є системні виклики та інтерфейс програмування застосувань (АРІ).

5.

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

Розглянемо послідовність виконання системного виклику.

  1.  Припустимо, що для процесу, який виконується в режимі користувача, потрібна функція, реалізована в ядрі системи.
  2.  Для того щоб звернутися до цієї функції, процес має передати керування ядру ОС, для чого необхідно задати параметри виклику і виконати програмне переривання (інструкцію системного виклику). Відбувається перехід у привілейований режим.
  3.  Після отримання керування ядро зчитує параметри виклику і визначає, що потрібно зробити.
  4.  Після цього ядро виконує потрібні дії, зберігає в пам'яті значення, які слід повернути, і передає керування програмі, що його викликала. Відбувається перехід назад у режим користувача.
  5.  Програма зчитує з пам'яті повернені значення і продовжує свою роботу.
  6.   Кожний системний виклик спричиняє перехід у привілейований режим і назад (у мікроядровій архітектурі, як було зазначено вище, таких переходів може бути і більше).

Є два основних способи передачі параметрів у системний виклик.

  •  передача параметрів у регістри процесора;
  •  занесення параметрів у певну ділянку пам'яті й передача покажчика на неї в регістрі процесора.

Системні виклики призначені для безпосереднього доступу до служб ядра ОС. На практиці вони не вичерпують (а іноді й не визначають) ті функції, які можна використати у прикладних програмах. Для доступу до засобів системних бібліотек ОС  використовують  інтерфейс програмування застосувань (Application Programming Interface, API).

Взаємозв'язок між функціями АРІ і системними викликами неоднаковий у різних ОС.

По-перше, кожному системному виклику може бути поставлена у відповідність бібліотечна функція, єдиним завданням якої є виконання цього виклику. Таку функцію називають пакувальником системного виклику (system call wrapper). Для програміста в цьому разі набір функцій АРІ виглядає як сукупність таких пакувальників і додаткових функцій, реалізованих бібліотеками повністю або частково в режимі користувача. Це рішення прийняте за основу в UNIX; у такому разі прийнято говорити про використання системних викликів у прикладних програмах (насправді у програмах викликають пакувальники системних викликів).

По-друге, можна надати для використання у прикладних програмах універсальний інтерфейс програмування застосувань (АРІ режиму користувача) і повністю сховати за ним набір системних викликів. Для програміста кожна функція такого АРІ є бібліотечною функцією режиму користувача, пакувальника в цьому разі немає, відомості про системні виклики є деталями реалізації ОС. Це властиве Windows-системам, де подібний універсальний набір функцій називають Win32 АРІ .

6.

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

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

Для сумісності на рівні вихідних текстів необхідно, щоб для всіх ОС існувала реалізація компілятора мови і АРІ, що його використовує програма.

Сьогодні таку сумісність забезпечує стандартизація розробки програмного забезпечення, а саме:

  •  наявність стандарту на мови програмування (насамперед на С і C++) і стандартних компіляторів;
  •  наявність стандарту на інтерфейс операційної системи (АРІ).

Робота зі стандартизації інтерфейсу операційних систем відбувається у рамках проекту POSIX (Portable Operating System Interface). Найбільш важливим стандартом є POSIX 1003.1 , який описує набір бібліотечних процедур (таких, як відкриття файла, створення нового процесу тощо), котрі мають бути реалізовані в системі. Цей процес стандартизації триває дотепер, останньою редакцією стандарту є базова специфікація Open Group/IEEE . Зазначені стандарти відображають традиційний набір засобів, реалізованих в UNIX-сумісних системах.

Завдання забезпечення бінарної сумісності виникає тоді, коли потрібно запустити на виконання файл прикладної програми у середовищі іншої операційної системи. Таке завдання значно складніше в реалізації, найпоширеніший підхід до його розв'язання - емуляція середовища виконання. У цьому разі програма запускається під керуванням іншої програми — емулятора, який забезпечує динамічне перетворення інструкцій програми в інструкції потрібної архітектури. Прикладом такого емулятора є програма wine, яка дає можливість запускати програми, розроблені для Win32 АРІ, у середовищі Linux через емуляцію функцій Win32 АРІ системними викликами Linux.

 Лекція №3.

Тема:  особливості архітектури: UNIX I Linux.

План:

1.Базова архітектура UNIX (Л1. ст.34-36).

2.Архітектура Linux: (Л1. ст.36-37).

призначення ядра Linux та його особливості,

модулі ядра,

особливості системних бібліотек,

застосування користувача.

1.

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

 

Cистема складається із трьох основних компонентів: підсистеми керування процесами, файлової підсистеми та підсистеми введення-виведення.

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

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

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

Сучасні UNIX-системи дещо відрізняються за своєю архітектурою.

У них виділено окремий менеджер пам'яті, відповідальний за підтримку віртуальної пам'яті.

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

У цих системах підтримується багатопроцесорна обробка, а також багатопото-ковість.

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

2.

В ОС Linux можна виділити три основні частини:

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

Призначення ядра Linux і його особливості

Linux реалізує технологію монолітного ядра. Весь код і структури даних ядра перебувають в одному адресному просторі. У ядрі можна виділити кілька функціональних компонентів [63].

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

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

Модулі ядра

Ядро Linux дає можливість на вимогу завантажувати у пам'ять і вивантажувати з неї окремі секції коду. Такі секції називають модулями ядра (kernel modules) і виконують у привілейованому режимі. Модулі ядра надають низку переваг.

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

Один модуль може зареєструвати кілька драйверів, якщо це потрібно (наприклад, для двох різних механізмів доступу до пристрою).

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

Особливості системних бібліотек

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

  •  реалізацію пакувальників системних викликів;
  •  розширення функціональності системних викликів (до таких бібліотек належить бібліотека введення-виведення мови С, яка реалізує на основі системних викликів такі функції, як prlntf ( ) );
  •  реалізацію службових функцій режиму користувача (сортування, функції обробки рядків тощо).

Застосування користувача

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

 Лекція №4.

Тема:  особливості архітектури: Windows XP.

План:

1.Компоненти режиму ядра Windows XP: (Л1. ст.38-40).

рівень абстрагування від устаткування, ядро, виконавча система, драйвери пристроїв,

віконна і графічна підсистеми

2.Компоненти режиму користувача: (Л1. ст.40-42).

бібліотека системного інтерфейсу, підсистеми середовища,наперед визначені            

системні процеси,  застосування користувача.

3.Об`єктна архітектура Windows XP: (Л1. ст.42-43).

структура заголовка об`акта, об`єкти типу, методи об`єктів, простір імен об`єктів.

1.

Деякі компоненти Windows ХР виконуються у привілейованому режимі, інші компоненти - у режимі користувача.

У традиційному розумінні  ядро ОС складають усі компоненти привілейованого режиму, однак у Windows ХР поняття ядра закріплене тільки за одним із цих компонентів.

Рівень абстрагування від устаткування

У Windows ХР реалізовано рівень абстрагування від устаткування (у цій системі його називають HAL, hardware abstraction layer). Для різних апаратних конфігурацій фірма Microsoft або сторонні розробники можуть постачати різні реалізації HAL.

Хоча код HAL є дуже ефективним, його використання може знижувати продуктивність застосувань мультимедіа. У такому разі використовують спеціальний пакет DirectX, який дає змогу прикладним програмам звертатися безпосередньо до апаратного забезпечення, обминаючи HAL та інші рівні системи.

Ядро

Ядро Windows ХР відповідає за базові операції системи. До його основних функцій належать:

  •  перемикання контексту, збереження і відновлення стану потоків;
  •  планування виконання потоків;
  •  реалізація засобів підтримки апаратного забезпечення, складніших за засоби HAL (наприклад, передача керування оброблювачам переривань).

Ядро Windows ХР відповідає базовим службам ОС і надає набір механізмів для реалізації політики керування ресурсами.

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

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

Виконавча система

Виконавча система (ВС) Windows ХР (Windows ХР Executive) - це набір компонентів, відповідальних за найважливіші служби ОС (керування пам'яттю, процесами і потоками, введенням-виведенням тощо).

Компонентами ВС є передусім базові засоби підтримки. Ці засоби використовують у всій системі.

Менеджер об'єктів — відповідає за розподіл ресурсів у системі, підтримуючи їхнє універсальне подання через об'єкти.

Засіб локального виклику процедур (LPC) — забезпечує механізм зв'язку між процесами і підсистемами на одному комп'ютері.

Інші компоненти ВС реалізують найважливіші служби Windows ХР. Зупинимося на деяких із них.

Менеджер процесів і потоків — створює та завершує процеси і потоки, а також розподіляє для них ресурси.

Менеджер віртуальної пам'яті — реалізує керування пам'яттю в системі, насамперед підтримку віртуальної пам'яті.

Менеджер введення-виведення — керує периферійними пристроями, надаючи іншим компонентам апаратно-незалежні засоби введення-виведення. Цей менеджер реалізує єдиний інтерфейс для драйверів пристроїв.

Менеджер кеша — керує кешуванням для системи введення-виведення. Часто використовувані блоки диска тимчасово зберігаються в пам'яті, наступні операції введення-виведення звертаються до цієї пам'яті, внаслідок чого підвищується продуктивність.

Менеджер конфігурації - відповідає за підтримку роботи із системним реєстром (registry) - ієрархічно організованим сховищем інформації про налаштування системи і прикладних програм.

Довідковий монітор захисту - забезпечує політику безпеки на ізольованому комп'ютері, тобто захищає системні ресурси.

Драйвери пристроїв

У Windows ХР драйвери не обов'язково пов'язані з апаратними пристроями. Застосування, якому потрібні засоби, доступні в режимі ядра, завжди варто оформляти як драйвер. Це пов'язане з тим, що для зовнішніх розробників режим ядра доступний тільки з коду драйверів.

Віконна і графічна підсистеми

Віконна і графічна підсистеми відповідають за інтерфейс користувача - роботу з вікнами, елементами керування і графічним виведенням.

  •  Менеджер вікон - реалізує високорівневі функції. Він керує віконним виведенням, обробляє введення з клавіатури або миші й передає застосуванням повідомлення користувача.
  •  Інтерфейс графічних пристроїв (Graphical Device Interface, GDI) — складається з набору базових операцій графічного виведення, які не залежать від конкретного пристрою (креслення ліній, відображення тексту тощо).
  •  Драйвери графічних пристроїв (відеокарт, принтерів тощо) — відповідають за взаємодію з контролерами цих пристроїв.

Під час створення вікон або елементів керування запит надходить до менеджера вікон, який для виконання базових графічних операцій звертається до GDI. Потім запит передається драйверу пристрою, затим - апаратному забезпеченню через НАL.

2.

Компоненти режиму користувача не мають прямого доступу до апаратного забезпечення, їхній код виконується в ізольованому адресному просторі. Більша частина коду режиму користувача перебуває в динамічних бібліотеках, які у Windows називають DLL (dynamiclink libraies).

Бібліотека системного інтерфейсу

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

Підсистеми середовища

Підсистеми середовища надають застосуванням користувача доступ до служб операційної системи, реалізуючи відповідний АРІ. Ми зупинимося на двох підсистемах середовища: Win32 і POSIX.

Підсистема Win32, яка реалізує Win32  АРІ, є обов'язковим компонентом Windows  ХР. До неї входять такі компоненти:

процес підсистеми Win32 (csrss.ехе), що відповідає, зокрема, за реалізацію текстового (консольного) введення-виведення, створення і знищення процесів та потоків;

бібліотеки підсистеми Win32, які надають прикладним програмам функції Win32 АРІ. Найчастіше використовують бібліотеки gdi32.dll (низькорівневі графічні функції, незалежні від пристрою), user32.dll (функції інтерфейсу користувача) і kernel32.dll (функції, реалізовані у ВС і ядрі).

Після того як застосування звернеться до функції Win32 АРІ, спочатку буде викликана відповідна функція з бібліотеки підсистеми Win32. Розглянемо варіанти виконання такого виклику.

  1.  Якщо функції потрібні тільки ресурси її бібліотеки, виклик повністю виконується в адресному просторі застосування без переходу в режим ядра.
  2.  Якщо потрібен перехід у режим ядра, з коду бібліотеки підсистеми виконується системний виклик. Так відбувається у більшості випадків, наприклад під час створення вікон або елементів керування.
  3.  Функція бібліотеки підсистеми може звернутися до процесу підсистеми Win32, при цьому:

коли потрібна тільки функціональність, реалізована даним процесом, переходу в режим ядра не відбувається;

коли потрібна функціональність режиму ядра, процес підсистеми Win32 виконує системний виклик аналогічно до варіанта 2.

Зазначимо, що до виходу Windows NT 4.0 (1996 рік) віконна і графічна підсистеми працювали в режимі користувача як частина процесу підсистеми Win32 (тобто виклики базових графічних функцій Win32 АРІ оброблялися відповідно до варіанта 3). Надалі для підвищення продуктивності реалізацію цих підсистем було перенесено в режим ядра [14].

Підсистема POSIX працює в режимі користувача й реалізує набір функцій, визначених стандартом POSIX 1003.1. Оскільки застосування, або прикладні програми (арріісатіопз), написані для однієї підсистеми, не можуть використати функції інших, у РОSІХ-програмах не можна користуватися засобами Win32 АРІ (зокрема, графічними та мережними функціями), що знижує важливість цієї підсистем-и. Підсистема РОSІХ не є обов'язковим компонентом Windows ХР.

Наперед визначені системні процеси

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

♦ Менеджер сесій (Sesion Manager, smss.exe) створюється в системі першим. Він запускає інші важливі процеси (процес підсистеми Win32, процес реєстрації в системі тощо), а також відповідає за їхнє повторне виконання під час аварійного завершення.

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

  •  Менеджер керування службами (Services Control Manager, services.exe) відповідає за автоматичне виконання певних застосувань під час завантаження системи. Застосування, які будуть виконані при цьому, називають службами (services). Такі служби, як журнал подій, планувальник задач, менеджер друкування, постачають разом із системою. Крім того, є багато служб сторонніх розробників; так зазвичай реалізовують серверні застосування (сервери баз даних, веб-сервери тощо).

Застосування користувача

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

3.

Керування ресурсами у Windows ХР реалізується із застосуванням концепції об'єктів. Об'єкти надають універсальний інтерфейс для доступу до системних ресурсів, для яких передбачено спільне використання, зокрема таких, як процеси, потоки, файли і розподілювана пам'ять. Концепція об'єктів забезпечує такі переваги:

  •  імена об'єктів організовані в єдиний простір імен, де їх легко знаходити.
  •  доступ до всіх об'єктів здійснюється однаково. Після створення нового об'єкта або після отримання доступу до наявного менеджер об'єктів повертає у застосування дескриптор об'єкта (оЬіесt handle).
  •  забезпечено захист ресурсів. Кожну спробу доступу до об'єкта розглядає підсистема захисту - без неї доступ до об'єкта, а отже і до ресурсу, отримати неможливо.

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

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

Структура заголовка об'єкта

Об'єкти складаються з двох частин: заголовка і тіла об'єкта. У заголовку міститься інформація, загальна для всіх об'єктів, у тілі - специфічна для об'єктів конкретного типу.

До атрибутів заголовка об'єкта належать:

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

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

Об'єкти типу

Формат і вміст тіла об'єкта визначається його типом. Новий тип об'єктів може бути визначений будь-яким компонентом ВС. Існує визначений набір типів об'єктів, які створюються під час завантаження системи (такі об'єкти, наприклад, відповідають процесам, відкритим файлам, пристроям введення-виведення).

Частина характеристик об'єктів є загальними для всіх об'єктів цього типу. Для зберігання відомостей про такі характеристики використовують спеціальні об'єкти типу (type objects). У такому об'єкті, зокрема, зберігають:

  •  ім'я типу об'єкта («процес», «потік», «відкритий файл» тощо);
  •  режими доступу (залежать від типу об'єкта: наприклад, для файла такими режимами можуть бути «читання» і «запис»).

Об'єкти типу недоступні в режимі користувача.

Методи об'єктів

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

  •  орen - викликається при відкритті дескриптора об'єкта;
  •  сlose - викликається при закритті дескриптора об'єкта;
  •  delete - викликається перед вилученням об'єкта з пам'яті.

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

Простір імен об'єктів

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

Device — імена пристроїв введення-виведення;

Driver - завантажені драйвери пристроїв;

ObjectTypes- об'єкти типів.

Простір імен об'єктів, як і окремі об'єкти, не зберігається після перезавантаження системи.

Висновки до розділу 2.

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

Контрольні запитання та завдання

  1.  Перелічіть причини, за якими ядро ОС має виконуватися в привілейованому режимі процесора.
  2.  Чи може процесор переходити у привілейований режим під час виконання програми користувача? Чи може така програма виконуватися виключно в привілейованому режимі?
  3.  У чому полягає головний недолік традиційної багаторівневої архітектури ОС? Чи має такий недолік архітектура з виділенням рівнів у монолітному ядрі?
  4.  Чому перехід до використання мікроядрової архітектури може спричинити зниження продуктивності ОС?
  5.  Автор Linux Лінус Торвальдс стверджує, що мобільність Linux має поширюватися на системи з «прийнятною» (reasonable) архітектурою. Які апаратні засоби повинна підтримувати така архітектура?
  6.  Наведіть переваги і недоліки реалізації взаємодії прикладної програми з операційною системою в Linux і Windows ХР.
  7.  Чи не суперечить використання модулів ядра принципам монолітної архітектури Linux? Поясніть свою відповідь.
  8.  Перелічіть переваги і недоліки архітектури ОС, відповідно до якої віконна і графічна підсистеми в Windows ХР виконуються в режимі ядра.
  9.  Чому деякі діагностичні утиліти Windows ХР складаються з прикладної програми і драйвера пристрою?

Розділ3.     Керування процесами і потоками та їх планування.

(аудиторних-6/5г. , самостійних- 8/5г.)

       

Лекція №1.

Тема:  базові поняття процесів і потоків.

План:

1.Процеси і потоки в сучасних ОС (Л1. ст.45-47).

2.Моделі процесів і потоків (Л1. ст.47).

3.Складові елементи процесів і потоків (Л1. ст.47).

4.Поняття паралелізму та його види (Л1. ст.48-49).

5.Переваги і недоліки багатопотоковості (Л1. ст49).

1.

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

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

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

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

Для успішного виконання програми потрібні певні ресурси. До них належать:

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

Ці групи ресурсів визначають дві складові частини процесу:

  •  послідовність виконуваних команд процесора;
  •  набір адрес пам'яті (адресний простір), у якому розташовані ці команди і дані для них.

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

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

Тепер можна дати ще одне означення процесу.

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

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

На відміну від процесів потоки розпоряджаються загальною пам'яттю. Дані потоку не захищені від доступу до них інших потоків за умови, що всі вони виконуються в адресному просторі одного процесу. Це надає додаткові можливості для розробки застосувань, але ускладнює програмування.

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

Адресний простір процесу не завжди відповідає адресам оперативної пам'яті. Наприклад, у нього можуть відображатися файли або регістри контролерів введення-виведення, тому запис за певною адресою в цьому просторі призведе до запису у файл або до виконання операції введення-виведення. Таку технологію називають відображенням у пам'ять (memory mapping).

2.

Максимально можлива кількість процесів (захищених адресних просторів) і потоків, які в них виконуються, може варіюватися в різних системах.

  •  В однозадачних системах є тільки один адресний простір, у якому в кожен момент часу може виконуватися один потік.
  •  У деяких вбудованих системах теж є один адресний простір (один процес), але в ньому дозволене виконання багатьох потоків. У цьому разі можна організовувати паралельні обчислення, але захист даних застосувань не реалізовано.
  •  У системах, подібних до традиційних версій UNIX, допускається наявність багатьох процесів, але в рамках адресного простору процесу виконується тільки один потік. Це традиційна однопотокова модель процесів. Поняття потоку в даній моделі не застосовують, а використовують терміни «перемикання між процесами», «планування виконання процесів», «послідовність команд процесу» тощо (тут під процесом розуміють його єдиний потік).
  •  У більшості сучасних ОС (таких, як лінія Windows ХР, сучасні версії UNIX) може бути багато процесів, а в адресному просторі кожного процесу — багато потоків. Ці системи підтримують багатопотоковість або реалізують модель потоків. Процес у такій системі називають багатопотоковим процесом.

Надалі для позначення послідовності виконуваних команд вживатимемо термін «потік», за винятком ситуацій, коли обговорюватиметься реалізація моделі процесів.

3.

До елементів процесу належать:

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

4.

Використання декількох потоків у застосуванні означає внесення в нього паралелізму (concurrency). Паралелізм — це одночасне (з погляду прикладного програміста) виконання дій різними фрагментами коду застосування. Така одночасність може бути реалізована на одному процесорі шляхом перемикання задач (випадок псевдопаралелізму), а може ґрунтуватися на паралельному виконанні коду на декількох процесорах (випадок справжнього паралелізму). Потоки абстрагують цю відмінність, даючи можливість розробляти застосування, які в однопроцесор-них системах використовують псевдопаралелізм, а при доданні процесорів — справжній паралелізм (такі застосування масштабуються зі збільшенням кількості процесорів).

 Види паралелізму

Можна виділити такі основні види паралелізму:

  •  паралелізм багатопроцесорних систем;
  •  паралелізм операцій введення-виведення;
  •  паралелізм взаємодії з користувачем;
  •  паралелізм розподілених систем.

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

Паралелізм операцій введення-виведення

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

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

Паралелізм взаємодії з користувачем

Під час інтерактивного сеансу роботи користувач може виконувати різні дії із застосуванням (і очікувати негайної реакції на них) до завершення обробки попередніх дій. Наприклад, після запуску команди «друкування документа» він може негайно продовжити введення тексту, не чекаючи завершення друкування.

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

Паралелізм розподілених застосувань

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

5.

За допомогою потоків вирішуються такі проблеми:

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

Незважаючи на перелічені переваги, використання потоків не є універсальним засобом розв'язання  проблем паралелізму, і пов'язане з деякими труднощами:

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

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

Лекція №2.

Тема: Способи реалізації моделі процесів і потоків та їх опис .

План:

1.Способи реалізації моделі потоків (Л1. ст.50-51).

2.Стани процесів і потоків (Л1. ст.51-52).

3.Опис процесів і потоків (Л1. ст.52).

4.Керуючі блоки процесів і потоків (Л1. ст.53).

5.Образи процесів і потоків (Л1. ст53-54).

1.

В ОС використовують два типи потоків – потоки користувача і потоки ядра

 Потік користувача — це послідовність виконання команд в адресному просторі процесу. Ядро ОС не має інформації про такі потоки, вся робота з ними виконується в режимі користувача. Засоби підтримки потоків користувача надають спеціальні системні бібліотеки; вони доступні для прикладних програмістів у вигляді бібліотечних функцій. Бібліотеки підтримки потоків у сучасних ОС реалізують набір функцій, визначений стандартом РОSІХ (відповідний розділ стандарту називають POSIX.1b); тут прийнято говорити про підтримку потоків РОSІХ.

Потік ядра - це послідовність виконання команд в адресному просторі ядра. Потоками ядра управляє ОС, перемикання ними можливе тільки у привілейованому режимі. Є потоки ядра, які відповідають потокам користувача, і потоки, що не мають такої відповідності.

  •  Процес

Співвідношення між двома видами потоків визначає реалізацію моделі потоків. Є кілька варіантів такої реалізації (схем багатопотоковості); розглянемо найважливіші з них (рис. 3.1).

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

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

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

Схема багатопотоковості М:N. У цій схемі присутні як потоки ядра, так і потоки користувача, які відображаються на потоки ядра так, що один потік ядра може відповідати декільком потокам користувача. Число потоків ядра може бути змінене програмістом для досягнення максимальної продуктивності. Розподіл потоків користувача по потоках ядра виконується в режимі користувача, планування потоків ядра - у режимі ядра. Схема є складною в реалізації і сьогодні здає свої позиції схемі 1:1.

2.

Для потоку дозволені такі стани:

  •  створення (new) — потік перебуває у процесі створення;
  •  виконання (running) — інструкції потоку виконує процесор (у конкретний момент часу на одному процесорі тільки один потік може бути в такому стані);
  •  очікування (waiting) — потік очікує деякої події (наприклад, завершення операції введення-виведення); такий стан називають також заблокованим, а потік - припиненим;
  •  готовність (ready) — потік очікує, що планувальник перемкне процесор на нього, при цьому він має всі необхідні йому ресурси, крім процесорного часу;
  •  завершення (terminated) — потік завершив виконання (якщо при цьому його ресурси не були вилучені з системи, він переходить у додатковий стан — стан зомбі).

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

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

Відносно систем, які реалізують модель процесів, прийнято говорити про стани процесів, а не потоків, і про планування процесів; фактично стани процесу в цьому разі однозначно відповідають станам його єдиного потоку.

У багатопотокових системах також можна виділяти стани процесів. Наприклад, у багатопотоковості, реалізованій за схемою М:1, потоки змінюють свої стани в режимі користувача, а процеси — у режимі ядра.

3.

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

Для керування розподілом ресурсів ОС повинна підтримувати структури даних, які містять інформацію, що описує процеси, потоки і ресурси. До таких структур даних належать:

  •  таблиці розподілу ресурсів: таблиці пам'яті, таблиці введення-виведення, таблиці файлів тощо;
  •  таблиці процесів і таблиці потоків, де міститься інформація про процеси і потоки, присутні у системі в конкретний момент.

4.

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

Керуючий блок потоку (Thread Control Block, ТСВ) відповідає активному потоку, тобто тому, який перебуває у стані готовності, очікування або виконання. Цей блок може містити таку інформацію:

  •  ідентифікаційні дані потоку (зазвичай його унікальний ідентифікатор);
  •  стан процесора потоку: користувацькі регістри процесора, лічильник інструкцій, покажчик на стек;
  •  інформацію для планування потоків.

Таблиця потоків — це зв'язний список або масив керуючих блоків потоку. Вона розташована в захищеній області пам'яті ОС.

Керуючий блок процесу (Process Control Block, РСВ) відповідає процесу, що присутній у системі. Такий блок може містити:

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

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

Таблицю процесів організовують аналогічно до таблиці потоків. Як елементи в ній зберігатимуться керуючі блоки процесів.

5.

Сукупність інформації, що відображає процес у пам'яті, називають образом процесу (process image), а всю інформацію про потік - образом потоку (thread image). До образу процесу належать:

  •  керуючий блок процесу;
  •  програмний код користувача;
  •  дані користувача (глобальні дані програми, загальні для всіх потоків);
  •   інформація образів потоків процесу.

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

До образу потоку належать:

  •  керуючий блок потоку;
  •  стек ядра (стек потоку, який використовується під час виконання коду потоку в режимі ядра);
  •  стек користувача (стек потоку, доступний у користувацькому режимі).

Схема розташування в пам'яті образів процесу і його потоків зображена нарис. 3.3. Усі потоки конкретного процесу можуть користуватися загальною інформацією його образу.

Лекція №3.

Тема: перемикання контексту й обробка переривань .

План:

1.Організація перемикання контексту (Л1. ст.54-55).

2.Обробка переривань (Л1. ст.55).

3.Створення процесів та їхня ієрархія (Л1. ст.56-57).

4.Особливості завершення процесів (Л1. ст.59).

5.Синхронне й асинхронне виконання процесів (Л1. ст.59).

6.Створення і завершення потоків (Л1. ст.60-61).

1.

Найважливішим завданням операційної системи під час керування процесами і потоками є організація перемикання контексту - передачі керування від одного потоку до іншого зі збереженням стану процесора.

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

  •  зберегти стан процесора потоку в деякій ділянці пам'яті (області зберігання стану процесора потоку);
  •  визначити, який потік слід виконувати наступним;
  •  завантажити стан процесора цього потоку із його області зберігання;
  •  продовжити виконання коду нового потоку.

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

           В архітектурі ІА-32 для збереження стану процесора кожної задачі (вмісту пов'язаних із нею регістрів процесора) використовують спеціальну ділянку пам'яті - сегмент стану задачі ТSS. Адресу цієї області можна одержати з регістра задачі ТR (це системний адресний регістр).

Для перемикання задач досить завантажити нові дані в регістр ТR. У результаті значення регістрів процесора поточної задачі автоматично збережуться в її сегменті стану, після чого в регістри процесора буде завантажено стан процесора нової (або раніше перерваної) задачі й почнеться виконання її інструкцій.

Наступний потік для виконання вибирають відповідно до принципів планування потоків.

2.

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

Наведемо приклад послідовності дій під час обробки переривання:

  •  збереження стану процесора потоку;
  •  встановлення стека оброблювача переривання;
  •  початок виконання оброблювача переривання (коду операційної системи); для цього з вектора переривання завантажується нове значення лічильника команд;
  •  відновлення стану процесора потоку після закінчення виконання оброблювача і продовження виконання потоку.

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

3.

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

Процеси можуть створюватися ядром системи під час її ініціалізації. Наприклад, в UNIX-сумісних системах таким процесом може бути процес ініціалізації системи іnit, у Windows ХР - процеси підсистем середовища (Win32 або POSIX). Таке створення процесів, однак, є винятком, а не правилом.

Найчастіше процеси створюються під час виконання інших процесів. У цьому разі процес, який створює інший процес, називають предком, а створений ним процес - нащадком.

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

Розрізняють два типи процесів з погляду їхньої взаємодії із користувачем - інтерактивні та фонові.

  •  Інтерактивні процеси взаємодіють із користувачами безпосередньо, приймаючи від них дані, введені за допомогою клавіатури, миші тощо. Прикладом інтерактивного процесу може бути процес текстового редактора або інтегрованого середовища розробки.
  •  Фонові процеси із користувачем не взаємодіють безпосередньо. Зазвичай вони запускаються під час старту системи і чекають на запити від інших застосувань. Деякі з них (системні процеси) підтримують функціонування системи (реалізують фонове друкування, мережні засоби тощо), інші виконують спеціалізовані задачі (реалізують веб-сервери, сервери баз даних тощо). Фонові процеси також називають службами (services, у системах лінії Windows ХР) або демонами (daemons, в UNIX).

  Ієрархія процесів

Після того як процес-предок створив процес-нащадок, потрібно забезпечити їхній взаємозв'язок. Є різні варіанти розв'язання цього завдання.

Можна організувати на рівні ОС однозначний зв'язок «предок-нащадок» так, щоб для кожного процесу завжди можна було визначити його предка. Наприклад, якщо процеси визначені унікальними ідентифікаторами, то для реалізації цього підходу в керуючому блоці процесу-нащадка повинен завжди зберігатися ідентифікатор процесу-предка або посилання на його керуючий блок.

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

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

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

4.

Існує три варіанти завершення процесів.

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

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

Процес завершується іншим процесом або ядром системи. Наприклад, перед закінченням роботи ОС ядро припиняє виконання всіх процесів. Процес може припинити виконання іншого процесу за допомогою системного виклику, який у POSIX-системах називають kill ().

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

5.

Коли у системі з'являється новий процес, для старого процесу є два основних варіанти дій:

  •  продовжити виконання паралельно з новим процесом - такий режим роботи називають асинхронним виконанням;
  •  призупинити виконання доти, поки новий процес не буде завершений, — такий режим роботи називають синхронним виконанням. (У цьому разі використовують спеціальний системний виклик, який у POSIX-системах називають wait().)

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

6.

Особливості створення потоків

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

Якщо процес створюється за допомогою системного виклику fork(), після розподілу адресного простору автоматично створюється потік усередині цього процесу (найчастіше це — головний потік застосування).

Можна створювати потоки з коду користувача за допомогою відповідного системного виклику.

У багатьох ОС є спеціальні потоки, які створює ядро системи (код ядра теж може виконуватися в потоках).

Під час створення потоку система повинна виконати такі дії.

Створити структури даних, які відображають потік в ОС.

Виділити пам'ять під стек потоку.

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

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

Локальні змінні функції потоку розташовані у стеку потоку і доступні лише його коду, глобальні змінні доступні всім потокам.

Особливості завершення потоків

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

Як і процеси, потоки можуть виконуватися синхронно й асинхронно. Потік, створивши інший потік, може призупинити своє виконання до його завершення. Таке очікування називають приєднанням потоків (thread joining, очікує той, хто приєднує). Після завершення приєднаного потоку потік, який очікував його завершення, може дістати статус виконання. Під час створення потоку можна визначити, чи підлягає він приєднанню (якщо потік не можна приєднати, його називають від'єднаним detached). Якщо потік не є від'єднаним (nondetached або joinable, такий потік називатимемо приєднуваним), після завершення його обов'язково потрібно приєднувати, щоб уникнути витікання пам'яті.

Рекомендації щодо розробки багатопотокових програм:

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

Розділ4.          Міжпроцесова взаємодія.

                  (аудиторних-6/4г. , самостійних- 8/4г.)

       

Лекція №1.

Тема:  види міжпроцесової взаємодії.

План:

1.Проблеми міжпроцесової взаємодії.

2.Види міжпроцесової взаємодії:

  1.  методи розподілюваної памяті
  2.  методи передавання повідомлень
  3.  технологія відображуваної памяті(Л1. ст. 149-151).

3.Міжпроцесова взаємодія на базі спільної пам’яті (Л1. ст.151).

1.

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

 Кожен потік виконується в рамках адресного простору свого процесу, тому часто постає задача організації взаємодії між потоками різних процесів. Ідеться власне про міжпроцесову взаємодію (interprocess communication, IPC). Ця технологія з'явилася задовго до поширення багатопотоковості.

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

2.

Реалізація міжпроцесової взаємодії здійснюється трьма основними методами: передавання повідомлень, розподілюваної пам'яті та відображуваної пам'яті. Ще одним методом IPC також можна вважати технологію сигналівхнє використання не зводиться тільки до організації IPC (синхронні сигнали є засобом оповіщення процесу про виняткову ситуацію); без них складно пояснити ряд базових понять керування процесами (наприклад, очікування завершення процесу).

Методи розподілюваної пам'яті

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

Методи передавання повідомлень

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

Технологія відображуваної пам'яті

Ще однією категорією засобів міжпроцесової взаємодії є відображувана пам'ять (mapped memory). У ряді ОС відображувана пам'ять є базовим системним механізмом, на якому ґрунтуються інші види міжпроцесової взаємодії та системні вирішення. Звичайно відображувану пам'ять використовують у поєднанні з інтерфейсом файлової системи, в такому разі говорять про файли, відображувані у пам'ять (memory-mapped files).

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

Файли, відображувані у пам'ять, будуть докладно розглянуті в розділі 11.

Особливості міжпроцесової взаємодії

Тепер можна порівняти характеристики міжпроцесової взаємодії із характеристиками взаємодії потоків одного процесу.

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

3.

Для вирішення проблеми міжпроцесової синхронізації необхідно:

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

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

Лекція №2.

Тема:  механізм передачі повідомлень.

План:

1.Основи передавання повідомлень (Л1. ст. 151-152).

2.Примітиви передавання повідомлень (Л1. ст. 152).

3.Синхронне й асинхронне предавання повідомлень (Л1. ст. 152-153).

1.

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

Як було вже згадано, засоби передавання повідомлень ґрунтуються на обміні повідомленнями - фрагментами даних змінної довжини. Основою такого обміну є не спільна пам'ять, а канал зв'язку (communication channel). Він забезпечує взаємодію між процесами (для того, щоб спілкуватися, вони повинні створити канал зв'язку) і є абстрактним відображенням мережі зв'язку. Абстрактність каналу дає змогу реалізувати його не тільки на основі мережної взаємодії, але й спільної пам'яті (коли процеси перебувають на одному комп'ютері). При цьому такі зміни в реалізації будуть сховані від процесів, що взаємодіють.

Виокремлюють такі характеристики каналів зв'язку: спосіб задання; кількість процесів, які можуть бути з'єднані одним каналом; кількість каналів, які можуть бути створені між двома процесами; пропускна здатність каналу (кількість повідомлень, які можуть одночасно перебувати в системі й бути асоційованими з цим каналом); максимальний розмір повідомлення; спрямованість зв'язку через канал (двобічний або однобічний зв'язок).

В однобічному зв'язку для конкретного процесу допускають передавання даних тільки в один бік.

2.

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

Є два примітиви передавання повідомлень: send (для відсилання повідомлення каналом) і гесеі ve (для отримання повідомлення з каналу).

Розглянемо, як особливості реалізації send і гесеі ve дають змогу виділити різні класи методів передавання повідомлень.

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

3.

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

  1.  Чи може потік бути призупинений під час виконання операції send, якщо повідомлення не було отримане?
  2.  Чи може потік бути призупинений під час виконання операції receive, якщо повідомлення не було відіслане?

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

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

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

  •  Якщо пропускна здатність дорівнює нулю (повідомлення не можуть очікувати в системі), відправник завжди має очікувати, поки одержувачу не надійде повідомлення, а одержувач має очікувати, поки повідомлення йому не буде відіслано. Два процеси мають явно домовлятися про майбутній обмін.
  •  Якщо пропускна здатність обмежена (у системі можуть перебувати максимум п повідомлень для цього каналу), відправник має очікувати тільки тоді, коли черга повідомлень для цього каналу переповнена (у ній перебуває рівно n повідомлень), одержувач має очікувати, якщо ця черга порожня.
  •  Якщо пропускна здатність необмежена, очікування можливе тільки для одержувача за порожньої черги.

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

Лекція №3.

Тема:  технології передавання повідомлень.

План:

1.Методи передавання повідомлень за допомогою каналів і черг (Л1 ст.154-155).

2.Методи обміну повідомленнями за допомогою сокетів  (Л1. ст. 155-157).

3.Віддалений виклик процедур (Л1 ст. 157).

1.

Канали

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

Розрізняють безіменні та поіменовані канали.

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

До поіменованих каналів (named pipes) є доступ за іменем. Такому каналу може відповідати, наприклад, файл у файловій системі, при цьому будь-який процес, який має доступ до цього файла, може обмінюватися даними через відповідний канал. Поіменовані канали реалізують непрямий обмін даними.

Обмін даними через канал може бути однобічним і двобічним.

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

Іншою технологією асинхронного непрямого обміну даними є застосування черг повідомлень (message queues). Для таких черг виділяють спеціальне місце в системній ділянці пам'яті ОС, доступне для застосувань користувача. Процеси можуть створювати нові черги, відсилати повідомлення в конкретну чергу й отримувати їх звідти. Із чергою одночасно може працювати кілька процесів. Повідомлення — це структури даних змінної довжини. Для того щоб процеси могли розрізняти адресовані їм повідомлення, кожному з них присвоюють тип. Відіслане повідомлення залишається в черзі доти, поки не буде зчитане. Синхронізація під час роботи з чергами схожа на синхронізацію для каналів.

2.

Найрозповсюдженішим методом обміну повідомленнями є використання сокетів (sockets). Ця технологія насамперед призначена для організації мережного обміну даними, але може бути використана й для взаємодії між процесами на одному комп'ютері (власне, мережну взаємодію можна розуміти як узагальнення IPC).

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

Особливості протоколу передавання даних і формування адреси сокету визначає комунікаційний домен; його потрібно зазначати під час створення кожного сокету. Прикладами доменів можуть бути домен Інтернету (який задає протокол зв'язку на базі TCP/IP) і локальний домен або домен UNIX, що реалізує зв'язок із використанням імені файла (подібно до поіменованого каналу). Сокет можна використовувати у поєднанні тільки з одним комунікаційним доменом. Адреса сокету залежить від домену (наприклад, для сокетів домену UNIX такою адресою буде ім'я файла).

Способи передавання даних через сокет визначаються його типом. У конкретному домені можуть підтримуватися або не підтримуватися різні типи сокетів.

Наприклад, і для домену Інтернет, і для домену UNIX підтримуються сокети таких типів:

  •  потокові (stream sockets) — задають надійний двобічний обмін даними суцільним потоком без виділення меж (операція читання даних повертає стільки даних, скільки запитано або скільки було на цей момент передано);
  •  дейтаграмні (datagram sockets) - задають ненадійний двобічний обмін повідомленнями із виділенням меж (операція читання даних повертає розмір того повідомлення, яке було відіслано).

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

Перед тим як почати працювати з сокетами, будь-який процес (і клієнт, і сервер) має створити сокет за допомогою системного виклику socket( ). Параметрами цього виклику задають комунікаційний домен і тип сокету. Цей виклик повертає дескриптор сокету - унікальне значення, за яким можна буде звертатися до цього сокету.

Подальші дії відрізняються для сервера і клієнта.  Для сервера виконуються такі дії:

  1.  Сокет пов'язують з адресою за допомогою системного виклику bind( ). Для сокетів домену UNIX як адресу задають ім'я файла, для сокетів домену Інтернету - необхідні характеристики мережного з'єднання. Далі клієнт для встановлення з'єднання й обміну повідомленнями має буде вказати цю адресу.
  2.  Сервер дає змогу клієнтам встановлювати з'єднання, виконавши системний виклик listen( ) для дескриптора сокету, створеного раніше.
  3.  Після виходу із системного виклику listen() сервер готовий приймати від клієнтів запити на з'єднання. Ці запити вишиковуються в чергу. Для отримання запиту із цієї черги і створення з'єднання використовують системний виклик accept( ). Внаслідок його виконання в застосування повертають новий сокет для обміну даними із клієнтом. Старий сокет можна використовувати далі для приймання нових запитів на з'єднання. Якщо під час виклику accept( ) запити на з'єднання в черзі відсутні, сервер переходить у стан очікування.

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

Після встановлення з'єднання (і на клієнті, і на сервері) з'явиться можливість передавати і приймати дані з використанням цього з'єднання. Для передавання даних застосовують системний виклик send( ), а для приймання - recv( ).

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

3.

Технологія віддаленого виклику процедур (Remote Procedure Call, RPC)  є прикладом синхронного обміну повідомленнями із підтвердженням отримання. Розглянемо послідовність кроків, необхідних для обміну даними в цьому разі.

  1.  Операцію send оформляють як виклик процедури із параметрами.
  2.  Після виклику такої процедури відправник переходить у стан очікування, а дані (ім'я процедури і параметри) доставляються одержувачеві. Одержувач може перебувати на тому самому комп'ютері, чи на віддаленій машині; технологія RPC приховує це. Класичний віддалений виклик процедур передбачає, що процес-одержувач створено внаслідок запиту.
  3.  Одержувач виконує операцію гесеі ve і на підставі даних, що надійшли, виконує відповідні дії (викликає локальну процедуру за іменем, передає їй параметри і обчислює результат).
  4.  Обчислений результат повертають відправникові як окреме повідомлення.
  5.  Після отримання цього повідомлення відправник продовжує своє виконання, розглядаючи обчислений результат як наслідок виклику процедури.

 

Розділ 5.          Керування оперативною пам’яттю.

                  (аудиторних-10/8г. , самостійних- 14/8г.)

       

Лекція №1.

Тема:  Основні поняття та вимоги до керування оперативною пам`яттю.

План:

1.Загальні положення керування оперативною пам’яттю (Л1 ст. 183)

2.Спільне використання фізичної пам’яті процесами та передумови введення віртуальної

   пам’яті (Л1 ст.184-185).

3.Поняття віртуальної пам’яті (Л1 ст.185-186).

  1.  Проблема фрагментації пам’яті (Л1 ст.186).
  2.  Логічна і фізична адресація пам’яті (Л1 ст.187).
  3.  Спільне використання пам’яті за допомогою базового та межового регістрів

  (Л1 ст.187-188).

1.

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

Різні види пам'яті організовані в ієрархію. На нижніх рівнях такої ієрархії перебуває дешевша і повільніша пам'ять більшого обсягу, а в міру просування ієрархією нагору пам'ять стає дорожчою і швидшою (а її обсяг стає меншим). Найдешевшим і найповільнішим запам'ятовувальним пристроєм є жорсткий диск комп'ютера. Його називають також допоміжним запам'ятовувальним пристроєм (secondary storage). Швидшою й дорожчою є оперативна пам'ять, що зберігається в мікросхемах пам'яті, встановлених на комп'ютері, - таку пам'ять називають основною пам'яттю (main memory). Ще швидшими засобами зберігання даних є різні кеші процесора, а обсяг цих кешів ще обмеженіший.

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

2.

Найпростіший з можливих способів спільного використання фізичної пам'яті кількома процесами це неперервний і послідовний її розподіл між усіма виконуваними програмами (рис. 8.1).

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

Якщо проаналізувати особливості розподілу пам'яті на основі цього підходу, можуть виникнути такі запитання.

  •  Як виконувати процеси, котрим потрібно більше фізичної пам'яті, ніж встановлено на комп'ютері?
  •  Що відбудеться, коли процес виконає операцію записування за невірною адресою (наприклад, процес Р2 - за адресою 0x7500)?
  •  Що робити, коли процесу (наприклад, процесу Р1) буде потрібна додаткова пам'ять під час його виконання?
  •  Коли процес отримає інформацію про конкретну адресу фізичної пам'яті, що з неї розпочнеться його виконання, і як мають бути перетворені адреси пам'яті, використані в його коді?
  •  Що робити, коли процесу не потрібна вся пам'ять, виділена для нього?

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

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

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

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

До адрес, використовуваних у програмах, ставляться такі вимоги.

Захист пам'яті. Помилки в адресації, що трапляються в коді процесу, повинні впливати тільки на виконання цього процесу. Коли процес Р2 зробить операцію записування за адресою 0x7500, то він і має бути перерваний за помилкою. Стратегія захисту пам'яті зводиться до того, що для кожного процесу виділяється діапазон коректних адрес, і кожна операція доступу до пам'яті перевіряється на приналежність адреси цьому діапазону.

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

3.

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

Завдяки віртуальній пам'яті фізична пам'ять адресного простору процесу може бути фрагментованою, оскільки основний обсяг пам'яті, яку займає процес, більшу частину часу залишається вільним. Є так зване правило «дев'яносто до десяти», або правило локалізації, яке стверджує, що 90 % звертань до пам'яті у процесі припадає на 10 % його адресного простору. Адреси можна переміщати так, щоб основній пам'яті відповідали тільки ті розділи адресного простору процесу, які справді використовуються у конкретний момент.

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

У такий спосіб можна значно збільшити розмір адресного простору процесу і забезпечити виконання процесів, що за розміром перевищують основну пам'ять

4.

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

Ще однією проблемою є фрагментація пам'яті, що виникає за ситуації, коли неможливо використати вільну пам'ять. Розрізняють зовнішню і внутрішню фрагментацію пам'яті (рис. 8.2).

Зовнішня зводиться до того, що внаслідок виділення і наступного звільнення пам'яті в ній утворюються вільні блоки малого розміру - діри (holes). Через це може виникнути ситуація, за якої неможливо виділити неперервний блок пам'яті розміру N, оскільки немає жодного неперервного вільного блоку, розмір якого S>N, хоча загалом обсяг вільного простору пам'яті перевищує N. Так, на рис. 8.2 для виконання процесу Р5 місця через зовнішню фрагментацію не вистачає.

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

5.

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

Логічна або віртуальна адреса - адреса, яку генерує програма, запущена на деякому процесорі. Адреси, що використовують інструкції конкретного процесора, є логічними адресами. Сукупність логічних адрес становить логічний адресний простір.Фізична адреса - адреса, якою оперує мікросхема пам'яті. Прикладна програма в сучасних комп'ютерах ніколи не має справи з фізичними адресами. Спеціальний апаратний пристрій MMU (memory management unit - пристрій керування пам'яттю) відповідає за перетворення логічних адрес у фізичні. Сукупність усіх доступних фізичних адрес становить фізичний адресний простір. Отже, якщо в комп'ютері є мікросхеми на 128 Мбайт пам'яті, то саме такий обсяг пам'яті адресують фізично. Логічно зазвичай адресують значно більше пам'яті.

Найпростіша схема перетворення адрес зображена на рис. 8.3.

Алгоритм перетворення логічних адрес у фізичні визначає принцип організації та керування пам`яттю.

6.

Під час реалізації віртуальної пам'яті необхідно забезпечити захист пам'яті, переміщення процесів у пам'яті та спільне використання пам'яті кількома процесами.

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

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

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

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

За такого підходу для процесу виділяють тільки одну пару значень «базова адреса-межа». Природним розвитком цієї ідеї стало відображення адресного простору процесу за допомогою кількох діапазонів фізичної пам'яті, кожен з яких задають власною парою значень базової адреси і межі. Так виникла концепція сегментації пам'яті.

Лекція №2.

Тема:  Сегментна та сторінкова організація пам`яті.

План:

1. Особливості сегментації пам’яті (Л1 ст.188-190).

2. Реалізація сегментації в архітектурі ІА-32 (Л1 ст.190-191).

3. Базові принципи сторінкової  організації пам’яті (Л1 ст.191-193).

4. Порівняльний аналіз сторінкової організації пам’яті та сегментації (Л1 ст.193).

1.

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

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

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

 Переваги сегментації пам'яті.

  •  З'явилася можливість організувати кілька незалежних сегментів пам'яті для процесу і використати їх для зберігання даних різної природи. При цьому права доступу до кожного такого сегмента можуть бути задані по-різному.
  •  Окремі сегменти можуть спільно використовуватися різними процесами, для цього їхні таблиці дескрипторів сегментів повинні містити однакові елементи, що описують такий сегмент.
  •  Фізична пам'ять, що відповідає адресному простору процесу, тепер не обов'язково має бути неперервною. Справді, сегментація дає змогу окремим частинам адресного простору процесу відображатися не в основну пам'ять, а на диск, і довантажуватися з нього за потребою, забезпечуючи виконання процесів будь-якого розміру.
  •  Цей підхід не позбавлений і недоліків.
  •  Необхідність введення додаткового рівня перетворення пам'яті (перерахунок логічних адрес у фізичні спричиняє зниження продуктивності (цей недолік властивий будь-якій повноцінній реалізації віртуальної пам'яті). Для ефективної реалізації сегментації потрібна відповідна апаратна підтримка.
  •  Керування блоками пам'яті змінної довжини з урахуванням необхідності їхнього збереженні* на диску може бути досить складним.
  •  Вимога, щоб кожному сегменту відповідав неперервний блок фізичної пам'яті відповідного розміру, спричиняє зовнішню фрагментацію пам'яті. Внутрішньої фрагментації у цьому разі не виникає, оскільки сегменти мають змінну довжину і завжди можна виділити сегмент довжини, необхідної для виконання програми.

Сьогодні сегментацію застосовують доволі обмежено передусім через фрагментацію і складність реалізації ефективного звільнення пам'яті та обміну із диском. Ширше використання отримав розподіл пам'яті на блоки фіксованої довжини - сторінкова організація пам'яті.

2.

В архітектурі ІА-32 догічні адреси в програмі формуються із використанням сегментації й мають такий вигляд: «селектор-зсув». Значення селектора завантажують у спеціальний регістр процесора (сегментний регістр) і використовують як індекс у таблиці дескрипторів сегментів, що перебуває в пам'яті та є аналогом таблиці сегментів, описаної раніше. В архітектурі ІА-32 підтримуються шість сегментних регістрів. Це означає, що виконуваний код в один і той самий час може адресувати шість незалежних сегментів.

Селектор містите індекс дескриптора в таблиці, біт індикатора локальної або глобальної таблиці та необхідний рівень привілеїв.

Для системи задають спільну глобальну таблицю дескрипторів (Global Descriptor Table, GDT), а для кожної задачі - локальну таблицю дескрипторів (Local Descriptor Table, LDT).

     Дескриптори в ІА-32 мають довжину 64 біти. Вони визначають властивості програмних об'єктів (наприклад, сегментів пам'яті або таблиць дескрипторів). 

Дескриптор містить значення бази (base), яке відповідає адресі об'єкта (наприклад, початок сегмента); значення межі (limit); тип об'єкта (сегмент, таблиця дескрипторів тощо); характеристики захисту.

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

Проте жодного разу не було згадано, що в дескрипторі зберігають фізичну адресу. Річ у тому, що для архітектури ІА-32 внаслідок перетворення логічної адреси отримують не фізичну адресу, а ще один вид адреси, який називають лінійною адресою.

3.

До основних технологій реалізації віртуальної пам'яті крім сегментації належить сторінкова організація пам'яті (paging). її головна ідея - розподіл пам'яті блоками фіксованої довжини. Такі блоки називають сторінками.

Ця технологія є найпоширенішим підходом до реалізації віртуальної пам'яті в сучасних операційних системах.

У разі сторінкової організації пам'яті логічну адресу називають також лінійною, або віртуальною, адресою. Такі адреси належать одній множині (наприклад, лінійною адресою може бути невід'ємне ціле число довжиною 32 біти).

Фізичну пам'ять розбивають на блоки фіксованої довжини - фрейми, або сторінкові блоки (frames). Логічну пам'ять, у свою чергу, розбивають на блоки такої самої довжини -сторінки (pages). Коли процес починає виконуватися, його сторінки завантажуються в доступні фрейми фізичної пам'яті з диска або іншого носія.

Сторінкова організація пам'яті повинна мати апаратну підтримку. Кожна адреса, яку генерує процесор, ділиться на дві частини: номер сторінки і зсув сторінки. Номер сторінки використовують як індекс у таблиці сторінок.

Таблиця сторінок - це структура даних, що містить набір елементів (page-table entries, PTE), кожен із яких містить інформацію про номер сторінки, номер відповідного їй фрейму фізичної пам'яті (або беспосередньо його базову адресу) та права доступу. Номер сторінки використовують для пошуку елемента в таблиці. Після його знаходження до базової адреси відповідного фрейму додають зсув сторінки, чим і визначають фізичну адресу (рис. 8.7).

 

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

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

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

 

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

4.

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

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

  •  Реалізація розподілу і звільнення пам'яті спрощується. Усі сторінки з погляду процесу рівноправні, тому можна підтримувати список вільних сторінок і в разі необхідності виділяти першу сторінку із цього списку, а після звільнення повертати сторінку в список. Із сегментами так чинити не можна, оскільки кожен сегмент можна використати лише за його призначенням (спроба використати сегмент для іншої мети призведе швидше за все до того, що виникне потреба у сегменті іншої довжини).
  •  Реалізація обміну даними з диском також спрощується. Для організації такого обміну ділянка на диску, яку використовують для зберігання інформації про сторінки, вивантажені з пам'яті {простір підтримки, backing store) може бути теж розбита на блоки фіксованого розміру, рівного розмірові фрейму.

Сторінкова організація пам'яті не позбавлена й недоліків.

  •   Насамперед цей підхід спричиняє внутрішню фрагментацію, пов'язану з тим, що розмір сторінки завжди фіксований, і в разі необхідності виділення блоку пам'яті конкретної довжини його розмір буде кратним розміру сторінки. У середньому розмір невикористовуваної пам'яті становить приблизно половину сторінки для кожного виділеного блоку пам'яті (аналогічного до сегмента). Така фрагментація може бути знижена зменшенням кількості та збільшенням розміру блоків, що виділяються.
  •  Таблиці сторінок мають бути більші за розміром, ніж таблиці сегментів. Так, для виділення неперервного діапазону пам'яті розміром 100 Кбайт знадобиться один елемент таблиці сегментів, що описує сегмент, виділений для цього діапазону. З іншого боку, у разі використання сторінок розміром 4 Кбайт для опису такого діапазону нам знадобиться 25 елементів таблиці сторінок - по одному елементу для кожної сторінки.

Лекція №3.

Тема:  Таблиці сторінок та сторінково-сегментна організація пам`яті.

План:

1. Багаторівневі таблиці сторінок (Л1 ст. 194).

2. Реалізація таблиць сторінок в архітектурі ІА-32 (Л1 ст.194-195).

3. Асоціативна пам’ять (Л1 ст.195-196).

4. Сторінково-сегментна організація пам’яті (Л1 ст.196-198).

1.

Щоб адресувати логічний адресний простір значного обсягу за допомогою однієї таблиці сторінок, її доводиться робити дуже великою. Наприклад, в архітектурі ІА-32 за стандартного розміру сторінки 4 Кбайт (для адресації всередині такої сторінки потрібні 12 біт) на індекс у таблиці залишається 20 біт, що відповідає таблиці сторінок на 1 мільйон елементів.

Щоб уникнути таких великих таблиць, запропоновано технологію багаторівневих таблиць сторінок. Таблиці сторінок самі розбиваються на сторінки, інформацію про які зберігають в таблиці сторінок верхнього рівня. Кількість рівнів рідко перевищує 2, але може доходити й до 4.

Коли є два рівні таблиць, логічну адресу розбивають на індекс у таблиці верхнього рівня, індекс у таблиці нижнього рівня і зсув.

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

2.

Архітектура ІА-32 використовує дворівневу сторінкову організацію, починаючи з моделі Intel 80386.

Таблицю верхнього рівня називають каталогом сторінок (page directory), для кожної задачі повинен бути заданий окремий каталог сторінок, фізичну адресу якого зберігають у спеціальному керуючому регістрі сгЗ і куди він автоматично завантажується апаратним забезпеченням при перемиканні контексту. Таблицю нижнього рівня називають просто таблицею сторінок (page table).

 Лінійна адреса поділяється на три поля:

  •  каталогу (Directory) - визначає елемент каталогу сторінок, що вказує на потрібну таблицю сторінок;

таблиці (Table) - визначає елемент таблиці сторінок, що вказує на потрібний фрейм пам'яті;

зсуву (Offset) — визначає зсув у межах фрейму, що у поєднанні з адресою фрейму формує фізичну адресу.

Розмір полів каталогу і таблиці становить 10 біт, що дає таблиці сторінок, які містять 1024 елементи, розмір поля зсуву - 12 біт, що дає сторінки і фрейми розміром 4 Кбайт. Одна таблиця сторінок нижнього рівня адресує 4 Мбайт пам'яті (1 Мбайт фреймів), а весь каталог сторінок  4 Гбайт.

Елементи таблиць сторінок всіх рівнів мають однакову структуру. Виокремимо такі поля елемента:

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

20 найбільш значущих бітів, які задають початкову адресу фрейму, кратну 4 Кбайт (може бути задано 1 Мбайт різних початкових адрес);

прапорець доступу (Accessed), який покладають рівним одиниці під час кожного звертання пристрою сторінкової підтримки до відповідного фрейму;

прапорець зміни (Dirty), який покладають рівним одиниці під час кожної операції записування у відповідний фрейм;

прапорець читання-записування (Read/Write), що задає права доступу до цієї сторінки або таблиці сторінок (для читання і для записування або тільки для читання);

прапорець привілейованого режиму (User/Supervisor), який визначає режим процесора, необхідний для доступу до сторінки. Якщо цей прапорець дорівнює нулю, сторінка може бути адресована тільки із привілейованого режиму, якщо одиниці - доступна також і з режиму користувача;

Прапорці присутності, доступу і зміни можна використовувати ОС для організації віртуальної пам'яті.

3.

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

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

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

Для розв'язання цієї проблеми було запропоновано технологію асоціативної пам'яті або кеша трансляції (translation look-aside buffers, TLB). У швидкодіючій пам'яті (швидшій, ніж основна пам'ять) створюють набір із кількох елементів (різні архітектури відводять під асоціативну пам'ять від 8 до 2048 елементів, в архітектурі ІА-32 таких елементів до Pentium 4 було 32, починаючи з Pentium 4 - 128). Кожний елемент кеша трансляції відповідає одному елементу таблиці сторінок.

Тепер під час генерування фізичної адреси спочатку відбувається пошук відповідного елемента таблиці в кеші (в ІА-32 — за полем каталогу, полем таблиці та зсуву), і якщо він знайдений, стає доступною адреса відповідного фрейму, що негайно можна використати для звертання до пам'яті. Якщо ж у кеші відповідного елемента немає, то доступ до пам'яті здійснюють через таблицю сторінок, а після цього елемент таблиці сторінок зберігають в кеші замість найстарішого елемента (рис. 8.9).

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

      Важливою характеристикою кеша трансляції є відсоток влучень, тобто відсоток випадків, коли необхідний елемент таблиці сторінок перебуває в кеші і не потребує доступу до пам'яті. Відомо, що при 32 елементах забезпечується 98 % влучень. Зазначимо також, що за такого відсотку влучень зниження продуктивності у разі використання дворівневих таблиць сторінок порівняно з однорівневими становить 28 %, однак переваги, отримувані під час розподілу пам'яті, роблять таке зниження допустимим.

4.

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

Для того щоб об'єднати переваги обох підходів, у деяких апаратних архітектурах (зокрема, в ІА-32) використовують комбінацію сегментної та сторінкової організації пам'яті. За такої організації перетворення логічної адреси у фізичну відбувається за три етапи.

              1.У програмі задають логічну адресу із використанням сегмента і зсуву.

              2.Логічну адресу перетворюють у лінійну (віртуальну) адресу за правилами, заданими для сегментації.

              3.Віртуальну адресу перетворюють у фізичну за правилами, заданими для сторінкової організації.

Таку архітектуру називають сторінково-сегментною організацією пам'яті.

Перетворення адрес в архітектурі ІА-32

Розглянемо особливості реалізації описаних трьох етапів перетворення адреси в архітектурі ІА-32.

  1.  Машинна мова архітектури ІА-32 (а, отже, будь-яка програма, розроблена для цієї архітектури) оперує логічними адресами. Логічна адреса, як було зазначено раніше, складається із селектора і зсуву.
  2.  Лінійна або віртуальна адреса — це ціле число без знака завдовжки 32 біти. За його допомогою можна дістати доступ до 4 Гбайт комірок пам'яті. Перетворення логічної адреси в лінійну відбувається всередині пристрою сегментації (segmentation unit) за правилами перетворення адреси на базі сегментації, описаними раніше.
  3.  Фізичну адресу використовують для адресації комірок пам'яті в мікросхемах пам'яті. її теж зображають 32-бітовим цілим числом без знака. Перетворення лінійної адреси у фізичну відбувається всередині пристрою сторінкової підтримки (paging unit) за правилами для сторінкової організації пам'яті (лінійну адресу розділяють апаратурою на адресу сторінки і сторінковий зсув, а потім перетворюють у фізичну адресу із використанням таблиць сторінок, кеша трансляції тощо).

Формування адреси у разі сторінково-сегментної організації пам'яті показане на рис. 8.10.

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

Лекція №3.

Тема:  Організація пам`яті в Linux.

План:

1. Використання сегментації в Linux, формування логічних адрес (Л1 ст.198-199).

2. Сторінкова адресація в Linux (Л1 ст.199).

3. Розташування ядра у фізичній пам’яті (Л1 ст.200).

4. Особливості адресації процесів і ядра (Л1 ст.200).

5. Використання асоціативної пам’яті (Л1 ст.200-201).

1.

Як уже зазначалося, необхідність підтримки сегментації призводить до того, що програми стають складнішими, оскільки задача виділення сегментів і формування коректних логічних адрес лягає на програміста. Цю проблему в Linux вирішують доволі просто - ядро практично не використовує засобів підтримки сегментації архітектури ІА-32. У системі підтримують мінімальну кількість сегментів, без яких неможлива коректна адресація пам'яті процесором (сегменти коду і даних ядра та режиму користувача). Код ядра і режиму користувача спільно використовує ці сегменти.

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

Усі сегменти, які використовуються у Linux, визначають межу зсуву, що дає змогу створити в рамках кожного з них 4 Гбайт логічних адрес. Це означає, що Linux фактично передає всю роботу з керування пам'яттю на рівень перетворення між лінійними і фізичними адресами (оскільки кожна логічна адреса відповідає лінійній).

Далі в цьому розділі вважатимемо логічні адреси вже сформованими (на базі відповідного сегмента) і перетвореними на лінійні адреси.

2.

   У ядрі Linux версії 2.4 використовують трирівневу організацію таблиць сторінок. Підтримуються три типи таблиць сторінок: глобальний (Page Global Directory, PGD); проміжний каталог сторінок (Page Middle Directory, PMD); таблиця сторінок (Page Table).

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

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

Тепер розглянемо роботу цієї трирівневої організації для архітектури ІА-32, яка дає можливість мати тільки два рівні таблиць. Насправді ситуація досить проста — проміжний каталог таблиць оголошують порожнім, водночас його місце в ланцюжку покажчиків зберігають для того, щоб той самий код міг працювати для різних архітектур. У цьому разі PGD відповідає каталогу сторінок ІА-32 (його елементи містять адреси таблиць сторінок), а під час роботи із покажчиком на PMD насправді працюють із покажчиком на відповідний йому елемент PGD, відразу отримуючи доступ до таблиці сторінок. Між таблицями сторінок Linux і таблицями сторінок ІА-32 завжди дотримується однозначна відповідність.

Для платформо-незалежного визначення розміру сторінки в Linux використовують системний виклик getpagesize( ):

#іпсіude <unistd.h>

ргіntf("Розмір сторінки: %d\n". getpagesize( ));

3.

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

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

На рис. 8.11 видно, як розташовується ядро у фізичній пам'яті, а також межі різних ділянок пам'яті ядра.

4.

Лінійний адресний простір кожного процесу поділяють на дві частини: перші З Гбайт адрес використовують у режимі ядра та користувача; вони відображають захищений адресний простір процесу; решту 1 Гбайт адрес використовують тільки в режимі ядра.

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

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

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

5.

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

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

Лекція №4.

Тема:  Організація пам`яті у Windows XP.

План:

1. Сегментація у Windows XP (Л1 ст.201).

2. Сторінкова адресація у Windows XP (Л1 ст.201).

3. Особливості адресації процесів і ядра (Л1 ст.201-202).

4. Структура адресного простору процесів і ядра (Л1 ст.202).

5. Висновки концепції керування оперативною пам’яттю (Л1 ст.202-203).

1.

Система Windows ХР використовує загальні сегменти пам'яті подібно до того, як це робиться в Linux. Для всіх сегментів у програмі задають однакові значення бази і межі, тому роботу з керування пам'яттю аналогічним чином передають на рівень лінійних адрес (які є зсувом у цих загальних сегментах).

2.

Під час роботи з лінійними адресами у Windows ХР використовують дворівневі таблиці сторінок, повністю відповідні архітектурі ІА-32. У кожного процесу є свій каталог сторінок, кожен елемент якого вказує на таблицю сторінок. Таблиці сторінок усіх рівнів містять по 1024 елементи таблиці сторінок, кожний такий елемент вказує на фрейм фізичної пам'яті. Фізичну адресу каталогу сторінок зберігають у блоці KPROCESS.

Розмір лінійної адреси, з якою працює система, становить 32 біти. З них 10 біт відповідають адресі в каталозі сторінок, ще 10 — це індекс елемента в таблиці, останні 12 біт адресують конкретний байт сторінки (і є зсувом).

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

Для платформо-незалежного визначення розміру сторінки у Win32 АРІ використовують універсальну функцію отримання інформації про систему GetSystemInfo( ):

SYSTEMINFO info;    // структура для отримання інформації про систему GetSystemInfo(&info);

printf("Розмір сторінки:  %d\n". info.dwPageSize);

3.

Лінійний адресний простір процесу поділяється на дві частини: перші 2 Гбайт адрес доступні для процесу в режимі користувача і є його захищеним адресним простором; інші 2 Гбайт адрес доступні тільки в режимі ядра і відображають системний адресний простір.

Зазначимо, що таке співвідношення між адресним простором процесу і ядра відрізняється від прийнятого в Linux (3 Гбайт для процесу, 1 Гбайт для ядра).

Деякі версії Windows ХР дають можливість задати співвідношення 3 Гбайт/1 Гбайт під час завантаження системи.

4.

В адресному просторі процесу можна виділити такі ділянки:

  •  перші 64 Кбайт (починаючи з нульової адреси) — це спеціальна ділянка, доступ до якої завжди спричиняє помилки;
  •  усю пам'ять між першими 64 Кбайт і останніми 136 Кбайт (майже 2 Гбайт) може використовувати процес під час свого виконання;
  •  далі розташовані два блоки по 4 Кбайт: блоки оточення потоку (ТЕВ) і процесу (РЕВ) (див. розділ 3);
  •  наступні 4 Кбайт — ділянка пам'яті, куди відображаються різні системні дані (системний час, значення лічильника системних годин, номер версії системи), тому для доступу до них процесу не потрібно перемикатися в режим ядра;
  •  останні 64 Кбайт використовують для запобігання спробам доступу за межі адресного простору процесу (спроба доступу до цієї пам'яті дасть помилку).

Системний адресний простір містить велику кількість різних ділянок. Найважливіші з них такі:

  •  Перші 512 Мбайт системного адресного простору використовують для завантаження ядра системи.
  •  4 Мбайт пам'яті виділяють під каталог сторінок і таблиці сторінок процесу.
  •  Спеціальну ділянку пам'яті розміром 4 Мбайт, яку називають гіперпростором (hyperspace), використовують для відображення різних структур даних, специфічних для процесу, на системний адресний простір (наприклад, вона містить список сторінок робочого набору процесу).
  •  512 Мбайт виділяють під системний кеш.
  •  У системний адресний простір відображаються спеціальні ділянки пам'яті - вивантажуваний пул і невивантажуваний пул, які розглянемо в розділі 10.
  •  Приблизно 4 Мбайт у самому кінці системного адресного простору виділяють під структури даних, необхідні для створення аварійного образу пам'яті, а також для структур даних HAL.

5.

  •  Керування пам'яттю є однією з найскладніших задач, які стоять перед операційною системою. Щоб нестача пам'яті не заважала роботі користувача, потрібно розв'язувати задачу координації різних видів пам'яті. Можна використовувати повільнішу пам'ять для збільшення розміру швидшої (на цьому ґрунтується технологія віртуальної пам'яті), а також швидшу - для прискорення доступу до повільнішої (на цьому ґрунтується кешування).
  •  Технологія віртуальної пам'яті передбачає введення додаткових перетворень між логічними адресами, які використовують програми, та фізичними, що їх розуміє мікросхема пам'яті. На основі таких перетворень може бути реалізований захист пам'яті; крім того, вони дають змогу процесу розміщатися у фізичній пам'яті не неперервно і не повністю (ті його частини, які в цей момент часу не потрібні, можуть бути збережені на жорсткому диску). Ця технологія спирається на той факт, що тільки частина адрес процесу використовується в конкретний момент часу, тому коли зберігати в основній пам'яті тільки її, продуктивність процесу залишиться прийнятною.
  •  Базовими підходами до реалізації віртуальної пам'яті є сегментація і сторінкова організація. Обидва ці підходи дають можливість розглядати логічний адресний простір процесу як сукупність окремих блоків, кожен з яких може бути відображений на основну пам'ять або на диск. Головна відмінність полягає в тому, що у випадку сегментації блоки мають змінну довжину, а у разі сторінкової організації — постійну. Сьогодні часто трапляється комбінація цих двох підходів (сторінково-сегментна організація пам'яті).
  •  У разі сторінкової організації пам'яті логічна адреса містить номер у спеціальній структурі даних - таблиці сторінок, а також зсув відносно початку сторінки. Розділення адреси на частини відбувається апаратно. Елемент таблиці сторінок містить адресу початку блоку фізичної пам'яті, у який відображається сторінка (такий блок називають фреймом) і права доступу. Він може також відповідати сторінці, відображеній на диск. Таблиці сторінок можуть містити кілька рівнів. Таблицю верхнього рівня називають каталогом сторінок. Кожний процес має свій набір таких таблиць. Для прискорення доступу останні використані елементи таблиць сторінок кешуються в асоціативній пам'яті.

Розділ 6.          Логічна та фізична організація файлових систем.

                  (аудиторних-8/6г. , самостійних- 12/8г.)

       

Лекція №1.

Тема:  Організація інформації у файловій системі.

План:

1. Поняття файла і файлової системи (Л1 ст.253-255).

2. Організація інформації розділами та каталогами у файловій системі (Л1 ст.255-257).

3. Зв’язок розділів і структури каталогів (Л1 ст.257-259).

4. Зв’язки між іменами файлів (Л1 ст.259-261).

5. Атрибути файлів (Л1 ст.261).

 6. Операції над файлами і каталогами (Л1 ст.261-262, 268).

1.

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

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

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

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

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

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

Типи файлів

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

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

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

Ще одним варіантом класифікації є поділ на файли із прямим і послідовним доступом. Файли із прямим доступом дають змогу вільно переходити до будь-якої позиції у файлі, використовуючи для цього поняття покажчика поточної позиції файла (seek pointer), що може переміщатися у будь-якому напрямку за допомогою відповідних системних викликів. Файли із послідовним доступом можуть бути зчитані тільки послідовно, із початку в кінець. Сучасні ОС звичайно розглядають усі файли як файли із прямим доступом.

Імена файлів

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

Різні системи висувають різні вимоги до імен файлів. Так, у деяких системах імена є чутливими до регістра (myfile.txt і MYFILE.TXT будуть різними іменами), а в інших - ні.

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

Важливою характеристикою файлової системи є максимальна довжина імені файла. У минулому багато ОС різним чином обмежували довжину імен файлів. Широко відоме було обмеження на 8 символів у імені файла і 3 - у розширенні, присутнє у файловій системі FAT до появи Windows 95. Сьогодні стандартним значенням максимальної довжини імені файла є 255 символів.

2.

Кожний розділ може мати свою файлову систему (і, можливо, використовуватися різними ОС). Для поділу дискового простору на розділи використовують спеціальну утиліту, яку часто називають fdisk.

 Для генерації файлової системи на розділі потрібно використати операцію високорівневого форматування диска. У деяких ОС під томом (volume) розуміють розділ із встановленою на ньому файловою системою.

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

Каталоги

Розділи є основою організації великих обсягів дискового простору для розгортання файлових систем. Для організації файлів у рамках розділу зі встановленою файловою системою було запропоновано поняття файлового каталогу (file directory) або просто каталогу.

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

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

Деревоподібна структура каталогів

Базовою ідеєю організації даних за допомогою каталогів є те, що вони можуть містити інші каталоги. Вкладені каталоги називають підкаталогами (subdirectories). Таким чином формують дерево каталогів. Перший каталог, створений у файловій системі, встановленій у розділі (корінь дерева каталогів), називають кореневим каталогом (root directory).

Поняття шляху

Розглянемо, яким чином формують ім'я файла з урахуванням багаторівневої структури каталогів.

Для файла, розташованого всередині каталогу недостатньо його імені для однозначного визначення, де він перебуває - в іншому каталозі може бути файл із тим самим ім'ям. Тепер для визначення місцезнаходження файла потрібно додавати до його імені список каталогів, де він перебуває. Такий список називають шляхом (path). Каталоги у шляху перераховують зліва направо - від меншої глибини вкладеності до більшої. Роздільник каталогів у шляху відрізняється для різних систем: в UNIX прийнято використовувати прямий слеш «/», а у Windows-системах - зворотний «\».

Абсолютний і відносний шляхи

Є два шляхи до файла: абсолютний і відносний. Абсолютний (або повний) повністю й однозначно визначає місце розташування файла. Такий шлях обов'язково має містити кореневий каталог. Ось приклад абсолютного шляху для UNIX-систем: /usr/local/bin/myfile.

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

Відносний - шлях, відлічуваний від деякого місця в ієрархії каталогів. Щоб його організувати, потрібно визначитися із точкою відліку, для чого використовують поняття поточного каталогу. Такий каталог задають для кожного процесу, і він може бути змінений у будь-який момент командою cd або системним викликом chdiг ( ). Відносний шлях може відлічуватися від поточного каталогу і звичайно кореневий каталог не включає. Прикладом відносного шляху до файла /usr/ local /bin/myfile (за умови, що поточним каталогом є /usr/local) буде bin/myfile, а в ситуації, коли поточним є каталог файла (/usr/local/bin), відносним шляхом буде просто ім'я файла: myfile.

Для спрощення побудови відносного шляху кожний каталог містить два спеціальні елементи:

  •  «.»- посилання на поточний каталог
  •  «..» - посилання на каталог рівнем вище-батьківський.

З урахуванням цих елементів можуть бути задані такі відносні шляхи, як ../../bin/myfile (за умови, що поточний каталог - /usr/local/lib/mylib) або ./myfile (вказує на елемент у поточному каталозі).

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

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

3.

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

Єдине дерево каталогів. Монтування файлових систем

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

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

Додаткові файлові системи об'єднуються із кореневою за допомогою операції монтування (mount). Під час монтування вибраний каталог однієї файлової системи стає кореневим каталогом іншої. Каталог, призначений для монтування файлової системи, називають точкою монтування (mount point). Весь вміст файлової системи, приєднаної за допомогою монтування, виглядає для користувачів системи як набір підкаталогів точки монтування.

Розглянемо операцію монтування на прикладі (рис. 11.1).

У цьому разі на диску є два розділи. На кожному з них встановлена файлова система (типи файлових систем можуть бути різними - це не є обмеженням; у каталозі системи одного типу можна змонтувати систему іншого типу за умови, що цей тип підтримує ОС). На рисунку точкою монтування ми вибрали каталог /usr першої файлової системи. Для користувача системи практично не помітно, що насправді каталог / і каталог /usr відповідають різним файловим системам. Відмінності можуть виявлятися, наприклад, під час спроби перенесення файла: виконання звичайної операції перенесення (mv у UNIX) між файловими системами не дозволяється.

Розглянемо деякі наслідки застосування єдиного каталогу для організації файлової системи.

  •  Будь-який файл може бути адресований побудовою відносного шляху від будь-якого каталогу.
  •  Від користувача прихована структура розділів жорсткого диска, яка йому у більшості випадків не потрібна.
  •  Адміністрування системи спрощується. Наприклад, якщо додамо ще один диск і захочемо перенести на нього каталог /home, достатньо буде виконати кілька простих дій: відформатувати цей диск, задавши на ньому один розділ; змонтувати цей розділ у довільному місці; перенести на нього каталог /home (стерши весь його вміст на вихідному диску); заново змонтувати цей розділ у каталозі /home кореневої файлової системи.

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

Літерні позначення розділів

Другий підхід, що в основному поширений в лініях Consumer Windows і Windows ХР, припускає, що кожний розділ зі встановленою файловою системою є видимим для користувача і позначений буквою латинського алфавіту. Такий розділ звичайно називають томом. Позначення томів нам знайомі — цеС:, D: тощо.

Особливості такої реалізації наведені нижче.

  •  Вміст кожного розділу не пов'язаний з іншими розділами; відносний шлях можна побудувати тільки за умови, що поточний каталог перебуває на тому самому томі, що і файл.
  •  Структура логічних розділів видима для користувача.
  •  Перенос каталогу на новий розділ призводить до того, що шлях до цього каталогу зміниться (оскільки такий шлях завжди включає літерне позначення тому). У підсумку програмне забезпечення, яке використовує цей шлях, може перестати працювати.
  •  У разі необхідності додавання або вилучення дискового пристрою у системах лінії Consumer Windows користувач не може впливати на те, які літери система присвоює розділам (фактично це залежить від порядку підключення апаратних пристроїв); у системах лінії Windows ХР користувач може вільно змінювати літерні позначення під час роботи системи.

Зазначимо, що нині в ОС лінії Windows ХР реалізована підтримка монтування (для файлової системи NTFS), що вирішує більшість перелічених проблем. Ця підтримка вперше з'явилась у Windows 2000 .

4.

Структура каталогів файлової системи не завжди є деревом. Багато файлових систем дає змогу задавати кілька імен для одного й того самого файла. Такі імена називають зв'язками (links). Розрізняють жорсткі та символічні зв'язки.

Жорсткі зв'язки

Ім'я файла не завжди однозначно пов'язане з його даними. За підтримки жорстких зв'язків (hard links) для файла допускається кілька імен. Усі жорсткі зв'язки визначають одні й ті самі дані на диску, для користувача вони не відрізняються: не можна визначити, які з них були створені раніше, а які - пізніше.

Підтримка жорстких зв'язків у POSIX

Для створення жорстких зв'язків у POSIX призначений системний виклик link().Першим параметром він приймає ім'я вихідного файла, другим — ім'я жорсткого зв'язку, що буде створений:

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

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

Підтримка жорстких зв'язків у Windows ХР

Жорсткі зв'язки здебільшого реалізовані в UNIX-сумісних системах, їх підтримують також у системах лінії Windows ХР для файлової системи NTFS . Для створення жорсткого зв'язку в цій системі необхідно використати функцію Create-HardLink ( ), ім'я зв'язку задають першим параметром, ім'я файла - другим, а третій дорівнює нулю:

CreateHardLink("myfile_hardlink.txt". "myfile.txt". 0);

Для вилучення жорстких зв'язків у Win32 АРІ використовують функцію

DeleteFile( ):

DeleteFi1е("myfіle_hardlіnk.txt");

Зазначимо, що для файлових систем, які не підтримують жорстких зв'язків, виклик DeleteFile( ) завжди спричиняє вилучення файла.

Жорсткі зв'язки мають певні недоліки, які обмежують їх застосування:

  •  не можуть бути задані для каталогів;
  •  усі жорсткі зв'язки одного файла завжди мають перебувати на одному й тому самому розділі жорсткого диска (в одній файловій системі);
  •  вилучення жорсткого зв'язку потенційно може спричинити втрати даних файла.

Символічні зв'язки

Символічний зв'язок (symbolic link) - зв'язок, фізично відокремлений від даних, на які вказує. Фактично, це спеціальний файл, що містить ім'я файла, на який вказує.

Наведемо властивості символічних зв'язків.

  •  Через такий зв'язок здійснюють доступ до вихідного файла.
  •  При вилученні зв'язку, вихідний файл не зникне.
  •  Якщо вихідний файл перемістити або вилучити, зв'язок розірветься, і доступ через нього стане неможливий, якщо файл потім поновити на тому самому місці, зв'язком знову можна користуватися.
  •  Символічні зв'язки можуть вказувати на каталоги і файли, що перебувають на інших файлових системах (на іншому розділі жорсткого диска). Наприклад, якщо створити в поточному каталозі зв'язок system-docs, що вказує на каталог /usr/doc, то перехід у каталог system-docs призведе до переходу в каталог /usr/doc.

Підтримка символічних зв'язків на рівні системних викликів

Для задания символічного зв'язку у POSIX визначено системний виклик symlіnk (), параметри якого

аналогічні до параметрів lіnk ():

symlink ("myfile.txt". "myfile-symlink.txt");

Для отримання шляху до файла або каталогу, на який вказує символічний зв'язок, використовують системний виклик readlink( ).

// РАТНМАХ - константа, що задає максимальну довжину шляху

 char filepath[PATH_MAX+l];

readlink("myfile-symlink.txt\ filepath, sizeof(filepath));

//уfilepathбуде шлях до myfile.txt

Символічні зв'язки вперше з'явилися у файлових системах UNIX, у Windows ХР вони підтримуються файловою системою NTFS під назвою точок з'єднання (junction points), але засоби АРІ для їхнього використання не визначені .

5.

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

  •  Ім'я файла.
  •  Тип файла, який задається для спеціальних файлів (каталогів, зв'язків тощо).
  •  Розмір файла ( для файла можна визначити його поточний, а іноді й максимальний розмір).
  •  Атрибути безпеки, що визначають права доступу до цього файла.
  •  Часові атрибути, до яких належать час створення останньої модифікації та останнього використання файла.

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

6.

Підходи до використання файлів із процесу бувають такі: зі збереженням (stateful) і без збереження стану (stateless).

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

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

Основні файлові операції, які надає ОС для використання у прикладних програмах за допомогою системних викликів через програмний інтерфейс АРІ наступні:

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

Лекція №2.

Тема:  Розміщення інформації у файлових системах.

План:

1. Базаві відомості про дискові пристрої: принцип дії жорсткого диска, ефективність   операцій доступу до диска (Л1 ст.284-286).

2. Розміщення інформації у файлових системах: фізична організація розділів на диску та основні вимоги до фізичної організації файлових систем (Л1 ст.286-287).

3. Неперервне розміщення файлів (Л1 ст.287-288).

4. Розміщення файлів зв’язними списками: прості зв’язні списки, зв’язні списки з таблицею розміщення файлів(Л1 ст.288-289).

1.

Накопичувачі на жорстких магнітних дисках (НЖМД) (рис. 12.1, далі - диски) складаються з набору дискових пластин (platters), які покриті магнітним матеріалом і обертаються двигуном із високою швидкістю.

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

      Головки зчитують інформацію із доріжок (tracks), які мають вигляд концентричних кіл. Мінімальна кількість доріжок на поверхні пластини в сучасних дисках — 700, максимальна — більше 20 000. Сукупність усіх доріжок одного радіуса на всіх поверхнях пластин називають циліндром.

Кожну доріжку під час низькорівневого форматування розбивають на сектори (sectors), обсяг даних сектора для більшості архітектур становить 512 байт (він обов'язково має дорівнювати степеню числа 2). Кількість секторів для всіх доріжок однакова (у діапазоні від 16 до 1600).

Основними характеристиками доступу до диска є:

  •  час пошуку (seek time) — час переміщення маніпулятора для позиціювання головки на потрібній доріжці (у середньому становить від 10 до 20 мс);
  •  ротаційна затримка (rotational delay) — час очікування, поки пластина повернеться так, що потрібний сектор опиниться під магнітною головкою (у середньому становить 8 мс);
  •  пропускна здатність передавання даних (transfer bandwidth) - обсяг даних, що передаються від пристрою в пам'ять за одиницю часу; для сучасних дисків ця характеристика порівнянна із пропускною здатністю оперативної пам'яті (200 Мбайт/с), час передавання одного сектора вимірюють у наносекундах.

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

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

У результаті час читання великих обсягів неперервно розташованих на диску даних усе менше відрізняється від часу читання малих. Як наслідок, першорядне значення для розробників файлових систем набуває розв'язання двох задач:

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

2.

Файлова система  будує базове відображення даних поверх того, яке їй надають драйвери дискових пристроїв.Драйвер дискового пристрою надає тільки посекторний доступ до диску, а ОС розподіляє дисковий простір не секторами, а спеціальними одиницями розміщення - кластерами (clusters) або дисковими блоками (disk blocks, термін «дисковий блок» більш розповсюджений в UNIX-системах). Визначення розміру кластера і розміщення інформації, необхідної для функціонування файлової системи, відбувається під час високорівневого форматування розділу. Саме таке форматування створює файлову систему в розділі.

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

Деякі застосування (насамперед, сервери баз даних) можуть реалізовувати свою власну фізичну організацію даних на диску. Для них файлова система може виявитися зайвим рівнем доступу, що тільки сповільнюватиме роботу. Багато ОС надають таким застосуванням можливість працювати із розділами, поданими у вигляді простого набору дискових секторів, який не містить структур даних файлової системи. Про такі розділи кажуть, що вони містять неорганізовану файлову систему (raw file system). Для них не виконують операцію високорівневого форматування.

Фізична організація розділів на диску

Початковий (нульовий) сектор диска називають головним завантажувальним записом (Master Boot Record, MBR). Наприкінці цього запису міститься таблиця розділів цього диска, де для кожного розділу зберігається початкова і кінцева адреси.

       Один із розділів диска може бути позначений як завантажувальний (bootable) або активний (active). Після завантаження комп'ютера апаратне забезпечення звертається до MBR одного з дисків, визначає з його таблиці розділів завантажувальний розділ і намагається знайти

в першому секторі цього розділу спеціальну невелику програму - завантажувач ОС (OS boot loader). Саме завантажувач ОС відповідає за пошук на диску і початкове завантаження у пам'ять ядра операційної системи. Далі у розділі розташовані структури даних файлової системи(системна область).

 Основні  вимоги  до  фізичної  організації файлових систем

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

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

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

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

3.

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

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

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

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

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

4.

Прості зв'язні списки.

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

Розміщення файлів з використанням зв'язних списків надає такі переваги:

  •  відсутність зовнішньої фрагментації (є тільки невелика внутрішня фрагментація, пов'язана з тим, що розмір файла може не ділитися націло на розмір кластера);
  •  мінімум інформації, яка потрібна для зберігання у заголовку файла (тільки посилання на перший кластер);
  •  можливість динамічної зміни розміру файла;
  •  простота реалізації керування вільними блоками, яке принципово не відрізняється від керування розміщенням файлів. Цей підхід, однак, не позбавлений і серйозних недоліків:
  •  відсутність ефективної реалізації випадкового доступу до файла: для того щоб одержати доступ до кластера з номером n , потрібно прочитати всі кластери файла з номерами від 1 до n-1;
  •  зниження продуктивності тих застосувань, які зчитують дані блоками, за розміром рівними степеню числа 2 (а таких застосувань досить багато): частина будь-якого кластера повинна містити номер наступного, тому корисна інформація в кластері займає обсяг, не кратний його розміру (цей обсяг навіть не є степенем числа 2);
  •  можливість втрати інформації у послідовності кластерів: якщо внаслідок збою буде втрачено кластер на початку файла, вся інформація в кластерах, що йдуть за ним, також буде втрачена.

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

з них є використання таблиці розміщення файлів.

Зв'язні списки з таблицею розміщення файлів

Цей підхід (рис. 12.4) полягає в тому, що всі посилання, які формують списки кластерів файла, зберігаються в окремій ділянці файлової системи фіксованого розміру, формуючи таблицю розміщення файлів (File Allocation Table, FAT). Елемент такої таблиці відповідає кластеру на диску і може містити:

  •  номер наступного кластера, якщо цей кластер належить файлу і не є його останнім кластером;
  •  індикатор кінця файла, якщо цей кластер є останнім кластером файла;
  •   індикатор, який показує, що цей кластер вільний.

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

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

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

І нарешті, службову інформацію більше не зберігають безпосередньо у кластерах файла, вивільняючи в них місце для даних. Тепер обсяг корисних даних всередині кластера майже завжди (за винятком, можливо, останнього кластера файла) дорівнюватиме степеню числа 2.

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

Також руйнування обох копій FAT (внаслідок апаратного збою або дії програми-зловмисника, наприклад, комп'ютерного вірусу) робить відновлення даних дуже складною задачею, яку не завжди можна розв'язати.

 

Лекція №3.

Тема:  Індексоване розміщення файлів

План:

1. Індексоване розміщення файлів (Л1 ст.290-291).

2. Структура індексних дескрипторів,розріджені файли (Л1 ст.291-293).

3. Організація каталогів (Л1 ст. 293-294).

4. Облік вільних кластерів (Л1 ст.294).

1.

Базовою ідеєю ще одного підходу до розміщення файлів є перелік адрес всіх кластерів файла в його заголовку. Такий заголовок файла дістав назву індексного дескриптора, або і-вузла node), а сам підхід - індексованого розміщення файлів.

За індексованого розміщення із кожним файлом пов'язують його індексний дескриптор. Він містить масив із адресами (або номерами) усіх кластерів цього файла, при цьому n елемент масиву відповідає n-му кластеру. Індексні дескриптори зберігають окремо від даних файла, для цього звичайно виділяють на початку розділу спеціальну ділянку індексних дескрипторів. В елементі каталогу розміщують номер індексного дескриптора відповідного файла (рис. 12.5).

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

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

2.

Основною проблемою є підбір розміру і задания оптимальної структури індексного дескриптора, оскільки:

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

Одне з компромісних розв'язань цієї задачі, яке застосовується вже багато років у UNIX-системах, зображене на рис. 12.6. Під час його опису замість терміна «кластер» вживатимемо його синонім «дисковий блок».

У цьому разі індексний дескриптор містить елементи різного призначення.

  •  Частина елементів (зазвичай перші 12) безпосередньо вказує на дискові блоки, які називають прямими (direct blocks). Отже, якщо файл може вміститися у 12 дискових блоках (за розміру блоку 4 Кбайт максимальний розмір такого файла становитиме 4096 х 12 = 49 152 байти), усі ці блоки будуть прямо адресовані його індексним дескриптором і жодних додаткових структур даних не буде потрібно.
  •   Якщо файлу необхідно для розміщення даних більше, ніж 12 дискових блоків, використовують непряму адресацію першого рівня. У цьому разі 13-й елемент індексного дескриптора вказує не на блок із даними, а на спеціальний непрямий блок першого рівня (single indirect block). Він містить масив адрес наступних блоків файла (за розміру блоку 4 Кбайт, а адреси - 4 байти в ньому міститимуться адреси 1024 блоків, при цьому максимальний розмір файла буде 4096 х (12 + 1024) = 4 234 456 байт).
  •  Якщо файлу потрібно для розміщення більше ніж 1024 + 12 = 1036 дискових блоків, використовують непряму адресацію другого рівня. 14-й елемент індексного дескриптора в цьому разі вказуватиме на непрямий блок другого рівня (double indirect block). Такий блок містить масив з 1024 адрес непрямих блоків першого рівня, кожен із них, як зазначалося, містить масив адрес дискових блоків файла. Тому за допомогою такого блоку можна адресувати 10242 додаткових блоків.
  •  Нарешті, якщо файлу потрібно більше ніж 1036 + 10242 дискових блоків, використовують непряму адресацію третього рівня. Останній 15-й елемент індексного дескриптора вказуватиме на непрямий блок третього рівня (triple indirect block), що містить масив з 1024 адрес непрямих блоків другого рівня, даючи змогу адресувати додатково 10243 дискових блоків.

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

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

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

Розріджені файли

Багато операційних систем не зберігають покажчики на дискові блоки файлів у їхніх індексних дескрипторах, поки до них не було доступу для записування. Фрагменти, до яких цього доступу не було з моменту створення файла, називають «дірами» (holes), дисковий простір під них не виділяють, але під час розрахунку довжини файла їх враховують. У разі читання вмісту «діри» повертають блоки, заповнені нулями, звертання до диска не відбувається.

На практиці «діри» найчастіше виникають, коли покажчик поточної позиції файла переміщують далеко за його кінець, після чого виконують операцію записування. У результаті розмір файла збільшується без додаткового виділення дискового простору. Подібні файли називають розрідженими файлами (sparse files). Вони реально займають на диску місця набагато менше, ніж їхня довжина, фактично довжина розрідженого файла може перевищувати розмір розділу, на якому він перебуває.

3.

Каталоги звичайно організують як спеціальні файли, що містять набір елементів каталогу (directory entries), кожен з яких містить запис про один файл.

Елементи каталогу.

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

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

Організація списку елементів каталогу. 

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

Організація підтримки довгих імен файлів

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

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

4.

Окрім урахування кластерів, виділених під файли, файлові системи повинні вести облік вільних кластерів. Це необхідно для того щоб система могла ефективно виділяти дисковий простір під нові файли. Найчастіше використовують два способи керування вільним дисковим простором:

  •  Бітовий масив - бітова карта кластерів, у якій кожен біт відповідає одному кластеру на диску. Якщо відповідний кластер вільний, біт дорівнює 1, якщо зайнятий-0. Головна перевага цього підходу в можливості його апаратної реалізації за рахунок простого алгоритму ( пошук першого ненульового біта), що дає змогу досягти максимальної швидкості.
  •  Зв’язний список вільних кластерів – використовують тоді, коли зв’язний список застосовується для розміщення файлів. До цього списку заносяться адреси вільних кластерів на диску. Елементами списку є кластери з адресами(номерами) вільних кластерів.

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

Лекція №4.

Тема:  Надійність файлових ситем.

План:

1. Оптимізація продуктивності під час розробки файлових систем (Л1 ст.295-296).

2. Надійність файлових систем (Л1 ст. 303-304).

3. Резервне копіювання (Л1 ст. 304-305).

4. Фізичне та логічне архівування. (Л1 ст. 305).

5. Системне відновлення у Windows XP (Л1 ст. 305).

6. Журнальні файлові системи (Л1 ст. 309-310).

1.

Розглянемо, яким чином можна оптимізувати продуктивність файлової системи зміною структур даних і алгоритмів, які в ній застосовують. У викладі використовуватимемо класичний приклад оптимізації традиційної файлової системи вихідної версії UNIX під час розроблення системи Fast File System (FFS) для BSD UNIX (у наш час ця файлова система також відома як ufs).

Традиційна файлова система UNIX складається із суперблока (що містить номери блоків файлової системи, поточну кількість файлів, покажчик на список вільних блоків), ділянки індексних дескрипторів і блоків даних (рис. 12.7). Розмір блока фіксований і становить 512 байт. Вільні блоки об'єднані у список.

Супер-блок

Індексні дескриптори

Блоки даних (по 512 байт)

                             Рис. 12.7. Традиційна файлова система UNIX

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

  •  Розмір дискового блоку виявився недостатнім, внаслідок чого для розміщення даних файла була потрібна велика кількість блоків; індексні дескриптори навіть для невеликих файлів потребували кількох рівнів непрямої адресації, перехід між якими сповільнював доступ; пересилання даних одним блоком призводила до зниження пропускної здатності.
  •  Пов'язані об'єкти часто виявлялися віддаленими один від одного і не могли бути зчитані разом, зокрема, індексні дескриптори були розташовані далеко від блоків даних і для каталогу не перебували разом; послідовні блоки для файла також не містилися разом (це траплялося тому, що протягом експлуатації системи через вилучення файлів список вільних блоків ставав «розкиданим» по диску, внаслідок чого файли під час створення отримували блоки, віддалені один від одного).

До розв'язання цих проблем під час розробки файлової системи FFS були запропоновані декілька підходів.

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

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

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

Внаслідок реалізації цих і деяких інших рішень пропускна здатність файлової системи зросла в 10-20 разів (до 40 % можливостей диска). На підставі цього прикладу можна зробити такі висновки:

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

Ідеї, що лежать в основі FFS, вплинули на особливості проектування файлової системи ext2fs - основної файлової системи Linux.

2.

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

  •  У разі використання дискового кеша дані, що перебувають у ньому, після відключення живлення зникнуть. Якщо до цього моменту вони не були записані на диск, зміни в них будуть втрачені. Більш того, коли такі зміни були частково записані на диск, файлова система може опинитися у суперечливому стані.
  •  Файлова система може опинитися у суперечливому стані внаслідок часткового виконання операцій із файлами. Так, якщо операція вилучення файла видалить відповідний запис із каталогу та індексний дескриптор, але через збій не встигне перемістити відповідні дискові блоки у список вільних блоків, вони виявляться «втраченими» для файлової системи, оскільки розмістити в них нові дані система не зможе.

Щоб забезпечити відновлення після системного збою, можна

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

3.

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

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

  •  Звичайно створюють резервні копії не всієї системи, а тільки певної підмножини її каталогів. Наприклад, каталоги із тимчасовими файлами архівувати не потрібно. Часто не архівують і системні каталоги ОС, якщо їх можна відновити із дистрибутивного диска.
  •  Крім того, у разі регулярного створення резервних копій є сенс організувати інкрементне архівування (increment backup), коли зберігаються тільки ті дані, які змінились із часу створення останньої копії. Є різні підходи до організації інкрементних архівів. Можна робити повну резервну копію через більший проміжок часу (наприклад, через тиждень), а інкрементні копії - додатково із меншим інтервалом (наприклад, через добу); можна зробити повну копію один раз, а далі обмежуватися тільки інкрементними копіями. Основною проблемою тут є ускладнення процедури відновлення даних.

У момент створення резервної копії важливим є забезпечення несуперечливості файлової системи. В ідеалі резервну копію треба створювати, коли дані файлової системи не змінюються (з нею не працюють інші процеси). На практиці цього домогтися складно, тому використовують спеціальні засоби, які «фіксують» стан системи на деякий момент часу.

4.

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

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

5.

Розглянемо приклад організації резервного копіювання на рівні ОС. Служба системного відновлення (System Restore) Windows ХР дає змогу повертати систему в точку відновлення (restore point) - заздалегідь відомий стан, у якому вона перебувала в минулому. За замовчуванням точку відновлення створюють кожні 24 години роботи системи, крім того, можна задавати такі точки явно (наприклад, під час встановлення програмного забезпечення).

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

Під час виконання операції відновлення (Restore) системні файли копіюють із каталогу точки відновлення у системний каталог Windows, після чого відновлюють змінені файли користувача на підставі інформації із журналу відновлення.

6.

Великий обсяг дисків робить виконання програми перевірки і відновлення під час завантаження після збою досить тривалим процесом (для диска розміром у десятки Гбайтів така перевірка може тривати кілька годин). У деяких ситуаціях (наприклад, на серверах баз даних з оперативною інформацією) подібні затримки із відновленням роботоздатності системи після кожного збою можуть бути недопустимими. Необхідно організувати збереження інформації таким чином, щоб відновлення після збою не вимагало перевірки всіх структур даних на диску. Спроби розв'язати цю проблему привели до виникнення журнальних файлових систем (logging file systems).

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

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

  1.  Спочатку інформацію зберігають у журналі (у ньому створюють новий запис). Таку операцію називають випереджувальним записуванням (write-ahead) або веденням журналу (journaling).

Коли ця операція повністю завершена (було підтверджено зміну журналу), інформацію записують у файлову систему (можливо, не відразу). Після того, як зміну журналу було підтверджено, усі записи в журналі, створені на етапі 1, стають непотрібними і можуть бути вилучені. Зауважимо, що синхронізація журналу і реальних даних на диску може відбуватися і явно; виконання такої операції називають точкою перевірки (checkpoint). Дані із журналу після цієї перевірки теж можуть бути вилучені.

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

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

Розмір журналу має бути достатній для того, щоб у ньому помістилися ті зміни, які на момент збою можуть перебувати у пам'яті.

Є різні підходи до того, яка інформація має зберігатися в журналі.

  •  Тільки описи змін у метаданих (до метаданих належить вся службова інформація: індексні дескриптори, каталоги, імена тощо). Такий журнал забезпечує несуперечливість файлової системи після відновлення, але не гарантує відновлення даних у файлах. З погляду продуктивності це найшвидший спосіб.
  •  Змінені кластери повністю. Такий підхід не вирізняється високою продуктивністю, натомість з'являється можливість відновити дані повністю. Файлові системи звичайно дають змогу вибрати варіант збереження інформації в журналі (це може бути зроблено під час монтування системи). На практиці вибір підходу залежить від конкретної ситуації.

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

  •  Збій відбувся до підтвердження зміни журналу. У цьому разі здійснюють відкат (rollback): цю зміну ігнорують, і файлова система залишається в несуперечливому стані, у якому вона була до операції. Зазначимо, що такі атомарні операції мають багато спільного із транзакціями — атомарними операціями у базі даних (відомо, що сервери баз даних для підтримки транзакцій також реалізують роботу із журналом).
  •  Збій відбувся після підтвердження зміни журналу. За цієї ситуації потрібно відновити дані на підставі інформації журналу (такий процес ще називають відкатом упередrolling forward).

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

Сучасні операційні системи все більше переходять до використання журнальних файлових систем; наприклад, для Linux є декілька їх реалізацій (ext3fs, ReiserFS, XFS). Файлова система NTFS також підтримує ведення журналу.

Розділ 7.          Керування пристроями вводу-виведення.

                  (аудиторних-8/6г. , самостійних- 10/6г.)

       

Лекція №1.

Тема:  Основні функції підсистеми вводу-виведення.

План:

1. Завдання підсистеми введення-виведення (Л1 ст. 358).

2. Забезпечення ефективності доступу до пристроїв (Л1 ст. 359).

3. Забезпечення спільного використання зовнішніх пристроїв (Л1 ст. 359).

4. Універсальність інтерфейсу прикладного програмування (Л1 ст. 359-360).

5. Універсальність інтерфейсу драйверів пристроїв (Л1 ст. 360-361).

6. Організація підсистеми введення –виведення (Л1 ст. 361-362).  

                                   

1.

Основним завданням підсистеми введення-виведення є реалізація доступу до зовнішніх пристроїв із прикладних програм, яка повинна забезпечити:

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

2.

Забезпечення ефективності вимагає розв'язання кількох важливих задач.

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

3.

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

  •  ОС повинна мати можливість забезпечувати одночасний доступ кількох процесів до зовнішнього пристрою і розв'язувати можливі конфлікти (тобто необхідна підтримка синхронізації доступу до пристроїв). Деякі пристрої (наприклад, модем або сканер) можна використати тільки одним процесом у конкретний момент часу, тоді як жорсткий диск завжди використовують спільно;
  •  Слід забезпечити захист пристроїв від несанкціонованого доступу. Такий захист можна організувати або для пристрою як цілого (наприклад, можна відкрити модем для доступу тільки певній групі користувачів), або для деякої підмножини даних пристрою (наприклад, різні файли на жорсткому диску можуть мати різні права доступу).
  •  У разі спільного використання пристрою треба розподілити операції введення-виведення різних процесів, для того щоб уникнути «накладок» даних одних процесів на дані інших (наприклад, під час спільного використання принтера важливо відрізняти одні задачі від інших і не переходити до друкування результатів наступної задачі до того, як завершилося виведення попередньої).

4.

Оскільки пристрої введення-виведення доволі різноманітні, дуже важливо уніфікувати доступ до них із прикладних програм. Для реалізації цієї ідеї підсистема введення-виведення має використовувати набір базових абстракцій, під час застосування яких можна надати доступ до різних зовнішніх пристроїв узагальненим способом. Для більшості сучасних ОС такою абстракцією є абстракція файла, що відображається як набір байтів, з яким можна працювати за допомогою спеціальних операцій файлового введення-виведення. До таких операцій належать, наприклад, системні виклики відкриття файла ореn ( ), файлового читання read ( ) і записування write ( ). Файл, що відповідає пристрою (його називають файлом пристрою), не відповідає набору даних на диску, а є засобом організації універсального доступу різних компонентів ОС і прикладних програм до деякого пристрою введення-виведення.

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

  1.  Розширити допустимий набір операцій, створивши інтерфейс, що відображає особливості конкретного пристрою. Його будують на основі стандартного файлового інтерфейсу, створюючи операції, характерні для конкретного пристрою. Ці операції, в свою чергу, використовують стандартні виклики, подібні до read ( ) і write ( ).
  2.  Надати прикладним програмам можливість взаємодіяти із драйвером пристрою безпосередньо. Для цього звичайно пропонують універсальний системний виклик (в UNIX його називають ioctl), у Windows ХР - DeviceIoControl ( ), параметри якого задають необхідний драйвер, команду, яку потрібно виконати, і дані для неї.

5.

Як відомо , драйвер пристрою - це програмний модуль, що керує взаємодією ОС із конкретним зовнішнім пристроєм.

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

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

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

6.

Загальна структура підсистеми введення-виведення показана на рис. 15.1.

Розглянемо особливості організації такої підсистеми.  

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

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

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

Лекція №3.

Тема:  Способи виконання операцій введення-виведення.

План:

1. Символьні, блокові та мережні драйвери пристроїв (Л1 ст. 362).

 2. Відокремлення механізму від політики за допомогою драйверів пристроїв (Л1 ст. 363). 

3. Способи виконання операцій введення-виведення (Л1 ст.363).

4. Опитування пристроїв (Л1 ст. 363-364).

5. Введення-виведення, кероване перериваннями (Л1 ст. 364-366).

6. Прямий доступ до пам`яті (Л1 ст. 366-367).

                                      

1.

Ще одна важлива класифікація драйверів уперше з'явилася в UNIX і відтоді її широко використовують, оскільки вона добре відображає специфіку різних пристроїв. Пристрої та драйвери відповідно до цієї класифікації розділяються на три категорії: блокові або блок-орієнтовані (block-oriented, block), символьні або байт-орієнтовані (character-oriented, character) і мережні (network).

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

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

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

2.

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

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

3.

Зовнішній пристрій взаємодіє із комп'ютерною системою через точку зв'язку, яку називають портом (port). Якщо кілька пристроїв з'єднані між собою і можуть обмінюватися повідомленнями відповідно до заздалегідь визначеного протоколу, то кажуть, що вони використовують шину (bus).

Як відомо, пристрої зв'язуються із комп'ютером через контролери. Є два базові способи зв'язку із контролером: через порт введення-виведення (I/O port) і відображувану пам'ять (memory-mapped I/O). У першому випадку дані пересилають за допомогою спеціальних інструкцій, у другому - робота із певною ділянкою пам'яті спричиняє взаємодію із контролером.

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

Спілкування із контролером через порт звичайно зводиться до використання чотирьох регістрів. Команди записують у керуючий регістр (control), дані - у регістр виведення (data-out), інформація про стан контролера може бути зчитана із регістра статусу (status), дані від контролера - із регістра введення (data-in). Ядро ОС має реєструвати всі порти введення-виведення і діапазони відображуваної пам'яті, а також інформацію про використання пристроєм порту і діапазону.

4.

Припустимо, що контролер може повідомити, що він зайнятий, увімкнувши біт busy регістра статусу. Застосування повідомляє про команду записування вмиканням біта wrіte командного регістра, а про те, що є команда - за допомогою біта сгеасіу того самого регістра. Послідовність кроків базового протоколу взаємодії з контролером (квітування, handshaking), наведено нижче.

  1.  Застосування у циклі зчитує біт busy, поки він не буде вимкнутий.
  2.  Застосування вмикає біт write керуючого регістра і відсилає байт у регістр виведення.
  3.  Застосування вмикає біт сгеасіу.
  4.  Коли контролер зауважує, що біт сгеасіу увімкнутий, то вмикає біт busy.
  5.  Контролер зчитує значення керуючого регістра і бачить команду write. Після цього він зчитує регістр виведення, отримує із нього байт і передає пристрою.
  6.  Контролер очищує біти сгеасіу і busy, показуючи, що операція завершена.

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

У більшості інших випадків потрібно організовувати введення-виведення, кероване перериваннями.

5.

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

Рівні переривань

Насамперед необхідно мати можливість скасовувати або відкладати обробку переривань під час виконання важливих дій.

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

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

Встановлення оброблювачів переривань

Контролер переривань здійснює роботу з перериваннями на апаратному рівні. Він є спеціальною мікросхемою, що дає змогу відсилати сигнал процесору різними лініями. Процесор вибирає оброблювач переривання, на який потрібно перейти, на підставі номера лінії, що нею прийшов сигнал. її називають лінією запиту переривання або просто лінією переривання (IRQ line). У старих архітектурах  застосовувалисяконтролери переривань, розраховані на 15-16 ліній переривання і на один процесор, сучасні системи мають спеціальні розширені програмовані контролери переривань (Advanced Programmable Interrupt Controllers, APIC), які реалізують багато ліній переривання (наприклад, для стандартного АРІС фірми Intel таких ліній 255) і коректно розподіляють переривання між процесорами за умов багатопроцесорних систем.

Ядро ОС зберігає інформацію про всі лінії переривань, доступні у системі. Драйвер пристрою дає запит каналу переривання (ÎRQ) перед використанням (встановленням оброблювача) і вивільняє після використання. Крім того, різні драйвери можуть спільно використовувати лінії переривань.

Оброблювач переривання може встановлюватися під час ініціалізації драйвера або першого доступу до пристрою (його відкриття). Через обмеженість набору ліній переривання частіше застосовують другий спосіб, у цьому разі, якщо пристрій не використовують, відповідна лінія може бути зайнята іншим драйвером.

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

  •  Розробник може надати користувачу право самому задати номер цієї лінії. Це — найпростіше вирішення, однак його слід визнати неприйнятним, тому що користувач не зобов'язаний знати номер лінії (для багатьох пристроїв його визначення пов'язане із дослідженням конфігурації перемичок на платі). Усі драйвери у сучасних ОС автоматично визначають номер переривання.
  •  Драйвер може використати ці номери прямо, оскільки для деяких стандартних пристроїв номер лінії переривання документований і незмінний (або, як для паралельного порту, однозначно залежить від базової адреси відображуваної пам'яті). Але так можна робити далеко не для всіх пристроїв.
  •  Драйвер може виконати зондування (probing) пристрою. Під час зондування драйвер посилає контролеру пристрою запити на генерацію переривань, а потім перевіряє, яка з ліній переривань була активізована. Проте цей підхід є досить незручним, і його вважають застарілим.
  •  І, нарешті, найкращим є підхід, за якого пристрій сам «повідомляє», який номер переривання він використає. У цьому разі завданням драйвера є просте визначення цього номера, наприклад, читанням регістра статусу одного із портів введення-виведення пристрою або спеціальної ділянки відображуваної пам'яті. Більшість сучасних пристроїв допускають таке визначення конфігурації. До них належать, наприклад, усі пристрої шини РСІ (для них це визначено специфікацією, інформацію зберігають у спеціальному просторі конфігурації), а також ISA-пристрої, що підтримують специфікацію Plug and Play.

6.

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

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

Усе це спонукало до розробки контролерів прямого доступу до пам'яті (direct memory access, DMA). Такий контролер сам керує пересиланням блоків даних від пристрою безпосередньо у пам'ять, не залучаючи до цього процесора. Блоки даних, які пересилають, завжди набагато більші, ніж розрядність процесора, наприклад вони можуть бути завдовжки 4 Кбайт. Схема введення-виведення при цьому наприклад, буде такою:

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

Процесор тут бере участь тільки на початку операції та в кінці - за все іншевідпо відає контролер прямого доступу до пам'яті.

Завдання ОС під час взаємодії із DMA-контролером досить складні, оскільки такі контролери відчутно відрізняються для різних архітектур і не завжди