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

 

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

 

У процедуру перемикання контексту входить т. н. планування завдання — процес ухвалення рішення до якого завдання передати управління.

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

Регістровий контекст регістрів загального призначення (у тому числі регістр прапора)

Контекст стану співпроцесора з плаваючою точкою

Стан регістрів MMX/SSE (x86)

Стан сегментних регістрів (x86)

Стан деяких регістрів(x86), що управляють

У ядрі ОС з кожним потоком пов'язані наступні структури:

· Загальна інформація pid, tid, uid, gid, euid, egid,.

· Стан процесу/потоку

· Права доступу

· Використовувані потоком ресурси і блокування

· Лічильники використання ресурсів (наприклад таймери використаного процесорного часу)

· Регіони пам'яті, виділені процесу

Крім того, що дуже важливо, при перемиканні контексту відбуваються наступні програмно-непомітні апаратні дії, що впливають на продуктивність :

Відбувається очищення конвеєра команд і даних процесора

Очищається TLB, що відповідає за сторінкове відображення лінійних адрес на фізичні

Крім того, слід врахувати наступні факти, що впливають на стан системи :

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

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

З точки зору прикладного рівня можна розділити voluntary і non - voluntary context switches: процес/, що Виконується, потік може сам передати управління іншому потоку або ядро само може відібрати управління.

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

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

Ядра, що синхронізують примітиви. Мьютексы, Семафори і т. д. Це і є основне джерело проблем з продуктивністю. Недостатньо продумана робота з синхронізуючими примітивами може в «поганих випадках» призводити до десяток тисяч, а при поганому проектуванні і сотням тисяч перемикань контексту в секунду.

Системний виклик явно очікуючий настання події (select, poll, epoll, pause, wait,.) або моменту часу (sleep, nanosleep,.). З точки зору продуктивності — це хороший варіант, ядро ОС завжди знає, хто чекає і чого чекає.

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

Методи зменшення кількості перемикань контексту :

Існує можливість конфігурації що виділяється потоку кванта процесорного часу. При зборці ядра Linux можливо вказати Server/Desktop/Low - Latency Desktop. Для серверних конфігурацій цей квант більший.

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

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

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

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

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

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

На сучасних ПК обробники основних апаратних і програмних переривань знаходяться в пам'яті BIOS. Сучасна операційна система, під час свого завантаження, замінює ці обробники своїми. При завантаженні драйверів пристроїв, операційна система розподіляє управління обробкою переривання між ними. У операційних системах сімейства Windows програмні переривання використовуються для викликів багатьох API функцій. У асемблері X86 переривання викликається командою int.

У сучасних системах обробники переривань діляться на Високопріоритетні Обробники Переривань (ВОП) і Низькопріоритетні Обробники Переривань (НОП).

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

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

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

У різних системах ВОП і НОП іменуються по-різному. У операційній системі Windows ВОП називається обробником переривання, а НОП — відкладений виклик процедури (DPC, Deferred Procedure Call)

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

Стан процесів

У багатозадачній (многопроцессной) системі процес може знаходитися в одному з трьох основних станів :

 

ВИКОНАННЯ - активний стан процесу, під час якого процес має усі необхідні ресурси і безпосередньо виконується процесором;

ОЧІКУВАННЯ - пасивний стан процесу, процес заблокований, він не може виконуватися зі своїх внутрішніх причин, він чекає здійснення деякої події, наприклад, завершення операції введення-виводу, отримання повідомлення від іншого процесу, звільнення якого-небудь необхідного йому ресурсу;

ГОТОВНІСТЬ - також пасивний стан процесу, але в цьому випадку процес заблокований у зв'язку із зовнішніми по відношенню до нього обставинами: процес має усі потрібні для нього ресурси, він готовий виконуватися, проте процесор зайнятий виконанням іншого процесу.

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

В змозі ВИКОНАННЯ в однопроцесорній системі може знаходитися тільки один процес, а в кожному із станів ОЧІКУВАННЯ і ГОТОВНІСТЬ - декілька процесів, ці процеси утворюють черги відповідно очікуючих і готових процесів. Життєвий цикл процесу розпочинається із стану ГОТОВНІСТЬ, коли процес готовий до виконання і чекає своєї черги. При активізації процес переходить в стан ВИКОНАННЯ і знаходиться в нім до тих пір, поки або він сам звільнить процесор, перейшовши в стан ОЧІКУВАННЯ якої-небудь події, або буде насильно "витіснений" з процесора, наприклад, внаслідок вичерпання відведеного цьому процесу кванта процесорного часу. У останньому випадку процес повертається в стан ГОТОВНІСТЬ. У цей же стан процес переходить із стану ОЧІКУВАННЯ, після того, як очікувана подія станеться.

Мал. 2.1. Граф станів процесу у багатозадачному середовищі

 

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

 

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

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

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

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

· створити інформаційні структури, що описують цей процес, тобто його дескриптор і контекст;

· включити дескриптор нового процесу в чергу готових процесів;

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

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

1. Що таке переключення контекстів та для чого воно використовується?

2. Як відбувається оброблення переривань?

3. Як відбувається керування процесами в умовах паралельного виконання?

Література

Електроний ресурс http://www.tup.km.ua/citforum/Opersys/sos/glava 6.htm