Операційні системи

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

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

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

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

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

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

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

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

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

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

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

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

§ Драйвери графічних пристроїв (відеокарт, принтерів тощо) -- відповідають за взаємодію з контролерами цих пристроїв.

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

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

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

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

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

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

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

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

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

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

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

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

Функція бібліотеки підсистеми може звернутися до процесу підсистеми 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.

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

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

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

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

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

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

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

Чи може процесор переходити у привілейований режим під час виконання програми користувача? Чи може така програма виконуватися виключно в привілейованому режимі?

У чому полягає головний недолік традиційної багаторівневої архітектури ОС? Чи має такий недолік архітектура з виділенням рівнів у монолітному ядрі?

Чому перехід до використання мікроядрової архітектури може спричинити зниження продуктивності ОС?

Автор Linux Лінус Торвальдс стверджує, що мобільність Linux має поширюватися на системи з «прийнятною» (reasonable) архітектурою. Які апаратні засоби повинна підтримувати така архітектура?

Наведіть переваги і недоліки реалізації взаємодії прикладної програми з операційною системою в Linux і Windows ХР.

Чи не суперечить використання модулів ядра принципам монолітної архітектури Linux? Поясніть свою відповідь.

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

Чому деякі діагностичні утиліти Windows ХР складаються з прикладної програми і драйвера пристрою?



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

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

План:

1.Процеси і потоки в сучасних ОС

2.Моделі процесів і потоків

3.Складові елементи процесів і потоків

4.Поняття паралелізму та його види

5.Переваги і недоліки багатопотоковості

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

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

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

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

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

§ ресурси, необхідні для послідовного виконання програмного коду (передусім процесорний час);

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

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

§ послідовність виконуваних команд процесора;

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

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

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

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

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

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

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

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

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

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

§ В однозадачних системах є тільки один адресний простір, у якому в кожен момент часу може виконуватися один потік.

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

§ У системах, подібних до традиційних версій UNIX, допускається наявність багатьох процесів, але в рамках адресного простору процесу виконується тільки один потік. Це традиційна однопотокова модель процесів. Поняття потоку в даній моделі не застосовують, а використовують терміни «перемикання між процесами», «планування виконання процесів», «послідовність команд процесу» тощо (тут під процесом розуміють його єдиний потік).

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

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

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

§ захищений адресний простір;

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

§ інформація про використання ресурсів (відкриті файли, мережні з'єднання тощо);

§ інформація про потоки процесу. Потік містить такі елементи:

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

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

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

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

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

§ паралелізм багатопроцесорних систем;

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

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

§ паралелізм розподілених систем.

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

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

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

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

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

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

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

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

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

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

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

§ для підтримки потоків потрібно менше ресурсів, ніж для підтримки процесів (наприклад, немає необхідності виділяти для потоків адресний простір).

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

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

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

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

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

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

План:

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

2.Стани процесів і потоків

3.Опис процесів і потоків

4.Керуючі блоки процесів і потоків

5.Образи процесів і потоків

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

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

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

Співвідношення між двома видами потоків визначає реалізацію моделі потоків.

Схема багатопотоковості М: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. Тема: перемикання контексту й обробка переривань

План:

1.Організація перемикання контексту

2.Обробка переривань

3.Створення процесів та їхня ієрархія

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

5.Синхронне й асинхронне виконання процесів

6.Створення і завершення потоків

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. Міжпроцесова взаємодія

Лекція №1. Тема: види міжпроцесової взаємодії

План:

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

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

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

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

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

3.Міжпроцесова взаємодія на базі спільної пам'яті

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

§ по-друге, розмістити в цій пам'яті стандартні синхронізаційні об'єкти (семафори, м'ютекси, умовні змінні);