- •Лекція №3
- •Розподілені сервісні системи
- •Тема 3. Процеси в розподілених сервісних системах.
- •6. Сервери.
- •7. Перенесення коду.
- •9. Програмні агенти.
- •1. Поняття процесу. Визначення і структура.
- •2. Потоки виконання. Визначення і структура.
- •3. Стан процесів та потоків виконання
- •4. Реалізація потоків виконання
- •4.1. Потоки виконання в нерозподілених системах
- •4.2. Потоки виконання в розподілених системах
- •4.3. Багатопотокові клієнти
- •4.4. Багатопотокові сервери
- •5.1. Інтерфейси користувача
- •5.2. Клієнтське програмне забезпечення і прозорість розподілу
- •6. Сервери
- •6.1. Підходи до побудови серверів прикладного програмного забезпечення
- •6.2. Сервери об’єктів
- •7. Перенесення коду
- •7.1. Підходи до перенесення коду
- •7.2. Моделі перенесення коду
- •8. Перенесення коду в гетерогенних системах
- •9. Програмні агенти
- •10.1. Програмні агенти в розподілених системах
- •10.3. Мови взаємодії агентів
- •Запитання для самоконтролю
4. Реалізація потоків виконання
Розрізняють два підходи реалізації потоків виконання: статичний і динамічний.
За статичним підходом кількість потоків виконання визначають вже на стадії написання програми або на стадії компіляції;кожному потоку виконання призначається фіксований стек. Цей підхід простий, але негнучкий.
Більш загальним є динамічний підхід, який дозволяє створювати і видаляти потоки виконання оперативно під час виконання. Системний виклик для створення потоку виконання зазвичай міститься в потоці головної програми у вигляді вказівника на процедуру із зазначенням розміру стека, а також інших параметрів, наприклад диспетчерського пріоритету. Виклик зазвичай повертає ідентифікатор потоку виконання, який можна використовувати в подальших викликах, пов’язаних із цим потоком. У цій моделі процес починається з одного потоку, але може створювати їх більше за необхідністю.
Завершуватися потоки можуть одним з двох способів: за власною ініціативою, коли завершується робота потоку, та ззовні.
4.1. Потоки виконання в нерозподілених системах
Найбільш важлива перевага використання потоків виконання в нерозподілених системах полягає у тому, що процеси з одним потоком виконання цілком блокуються під час будь-якого блокуючого системного виклику.
Приклад. Як ілюстрацію розглянемо певне програмне забезпечення, наприклад електронні таблиці. Важливою властивістю електронних таблиць є підтримка функціональних залежностей між різними елементами таблиці або різними таблицями. Таким чином, кожного разу у процесі модифікації комірки, всі комірки, пов’язані з нею, автоматично оновлюються. Уявимо, що користувач хоче постійно змінювати значення комірки в інтерактивному режимі. Після того, як користувач змінить значення однієї з комірок, внесена ним зміна спричине значний обсяг обчислень. Якщо працювати лише з одним потоком виконання, то під час очікування введення даних ці обчислення виявляться неможливими. Так само складно ввести дані під час виконання процесу обчислень. Найпростішим рішенням є створення як мінімум двох потоків виконання: один для підтримки роботи з користувачем, другий для оновлення таблиць.
Багатопотокову структуру часто використовують, будуючи великі програмні комплекси, які часто розробляють у вигляді наборів спільно працюючих програм, кожна з яких виконується окремим процесом. Цей підхід типовий для середовища UNIX. Кооперація між програмами реалізується у вигляді міжпроцесної взаємодії (через механізми Interproccessing Cooperation – IPC). Для UNIX-систем ці механізми зазвичай застосовують канали (поіменовані), черги повідомлень і спільно використовувані сегменти пам’яті. Основною проблемною властивістю механізмів IPC є необхідність інтенсивного перемикання контекстів, яка продемонстрована трьома точками на рис.4.
Рис. 4. Перемикання контекстів в результаті виклику IPC
Оскільки механізм IPC має втручатися в ядро, процес зазвичай вимушений спочатку перемкнутися з призначеного для користувача режиму в режим ядра (точка S1), що потребує зміни карти пам'яті в блоці MMU, а також очищення буфера TLB. У ядрі відбувається перемикання контексту процесу (точка S2), після чого другий процес може бути активізований черговим перемиканням з режиму ядра у призначений для користувача режим (точка S3). Останнє перемикання теж потребує зміни карти пам’яті у блоці MMU і очищення_буфера_TLB.
