Потоки виконання

Лекцiя 7

Тема: Процеси розподiлених систем

Потоки виконання

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

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

За контекстом потокiв можна виокремити особливостi реалiзацiї потокiв для розподiлених i нерозподiлених систем. Багатопотоковi реалiзацiї в них мають рiзнi особливостi. У нерозподiлених системах багатопотоковi процеси не блокуються за наявностi блокувальних системних викликiв потокiв. Багатопотокову структуру часто застосовують для побудови великих додаткiв, що характерно, наприклад, для середовища UNIX. Схему взаємодiї двох процесiв показано на рис. 8.1.

Мiжпроцесорна взаємодiя через механiзм мiжпроцесорних комунiкацiй IPC (Inter Process Communication) передбачає наявнiсть каналiв (iменованих), черги повiдомлень i сегментiв пам'ятi сумiсного використання.

Перемикання S1 потребує змiни карти пам'ятi у блоцi керування пам'яттю MMU (Memory Management Unit), а також скидання асоцiативного буфера сторiнок TLB (Translation Lookaside Buffer). У ядрi вiдбувається перемикання S2, за яким може бути активiзовано перемикання S3, що знову змiнює карти пам'ятi MMU i TLB.

Рис. 8.1. Схема перемикання контекстiв пiд час виконання IPC: S1 - перемикання з простору користувача в простiр ядра; S2 - перемикання контексту з процесу А на процес В; S3 - перемикання з простору ядра ОС у простiр користувача.

Замiсть цього можна органiзувати багатопотокове виконання процесу з використанням розподiлення пам'ятi в просторi користувача мiж окремими потоками. При цьому можна спростити сам процес розроблення додаткiв.

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

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

Рис. 8.2. Схема виконання полегшених процесiв рiвня ядра i потокiв рiвня користувача

Тому застосовують комбiнованi полегшенi процеси LWP (Light Weight Processes), як показано на рис. 8.2.

На один процес може бути кiлька полегшених процесiв. Система надає пакет потокiв для асинхронного виконання на користувацькому рiвнi додатками операцiй зi створення i знищення потокiв виконання.

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

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

Недолiком використання полегшених процесiв є потреба їх створення. Альтернативою є пiдхiд активiзацiї планувальника (scheduler activations), за яким функцiї планувальника передаються в пакет потокiв пiд час блокування ядра.

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

Зокрема, клiєнт як багатопотоковий Web-браузер спочатку отримує основний HTML-файл, а далi активiзує потоки виконання, якi вiдповiдають за довантаження iнших частин сторiнки. Кожний потiк виконує окремi з'єднання iз сервером i отримує данi, зокрема iз застосуванням блокувальних системних викликiв.

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

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

Багатопотоковий сервер, органiзований за схемою "диспетчер-робочий потiк", показано на рис. 8.3.

Рис. 8.3. Багатопотоковий сервер за схемою "диспетчер-робочий потiк"

Нехай файловий сервер перiодично блокується очiкуванням диску. "Потiк-диспетчер" зчитує вхiднi

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

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

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

Таким чином, потоки дозволяють зберегти iдею послiдовностi процесiв (зокрема, пiд час RPC роботи з диском) i паралельнiсть роботи, що пiдвищує продуктивнiсть роботи системи.

Поиск по сайту: