Реалізація багатозадачності в Windows Vista

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1.3. Реалізяція багатозадачності в Windows Vista

1.3.1.Фундаментальні концепції

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

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

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

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

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

Процес може знаходитися  всередині тільки для одного завдання (максимум).

Рис. 1.3.1.1. Зв'язок між завданнями, процесами, потоками і волокнами. 

На рис. 1.3.1.1. показаний зв'язок між завданнями (jobs), процесами (processes), потоками (threads) і волокнами (fibers). Завдання містять процеси. Процеси містять потоки. Але потоки не містять волокна. Зв'язок між потоками і волокнами зазвичай має тип «багато-до-багатьох».

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

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

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

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

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

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

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

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

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

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

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

Третій механізм синхронізації  називається «критична секція» (critical section). Він реалізує концепцію «критичних областей». У Windows він схожий на мьютекс, за винятком того, що він є локальним для адресного простору створюючого потоку. Оскільки критичні секції не є об'єктами режиму ядра, вони не мають явних описувачів або дескрипторів безпеки і не можуть передаватися між процесами. Блокування та розблокування виконується відповідно викликами EnterCriticalSection і LeaveCriticalSection. Оскільки ці функції API виконуються спочатку в просторі користувача і роблять виклики ядра тільки при необхідності в блокуванні, то вони набагато швидші мьютекс. Критичні секції оптимізовані для комбінованого використання спін-блокувань (на багатопроцесорних системах) і синхронізації ядра (при необхідності). У багатьох додатках більшість критичних секцій так рідко стають об'єктом суперництва або мають таке короткий час утримування, що необхідність у виділенні об'єкта синхронізації ядра ніколи не виникає. Це призводить до дуже істотної економії пам'яті ядра.

 

 

 

1.3.2. Реалізація процесів і потоків в Windows Vista

Розглянемо, як у Windows Vista створюється  процес (і початковий потік). Процес створюється тоді, коли інший процес робить виклик CreateProcess інтерфейсу Win32. Цей виклик запускає процедуру (користувальницького режиму) з kernel.dll, яка створює :

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

2. Збираються всі параметри  створення процесу і передаються  (разом з повним маршрутом до виконуваній програмі) власному інтерфейсу NtCreateUserProcess. (Цей API був доданий в Windows Vista для того, щоб подробиці створення процесу можна було реалізовувати в режимі ядра, дозволяючи використовувати процеси як кордони безпеки. Попередні власні API і раніше існують, але викликом CreateProcess вони більше не використовуються.)

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

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

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

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

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

8. Виконавчий рівень створює  і ініціалізує блок Process Environment Block (РЕВ) користувальницького режиму, який використовується як користувальницьким режимом, так і ядром для підтримки інформації про стан процесу.

9. У новому процесі  виділяється віртуальна пам'ять,  яка використовується для передачі  параметрів (в тому числі рядків  оточення і командного рядка).

10. Із спеціальної таблиці  описувачів (яку підтримує ядро ​​для ефективного виділення локально-унікальних ідентифікаторів для процесів і потоків) виділяється ідентифікатор процесу.

11. Виділяється і ініціалізується об'єкт потоку. Виділяється стек користувацького режиму і блок Thread Environment Block (Тев). Ініціалізується запис CONTEXT, який містить початкові значення регістрів процесора для потоку (в тому числі покажчики команд і стека).