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

12. Об'єкт процесу додається  в глобальний список процесів. У таблиці описувачів викликаної сторони виділяється місце під описувачі для об'єктів процесу і потоку. Для початкового потоку виділяється ідентифікатор (з таблиці ідентифікаторів).

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

14. Якщо інтерфейс NT API дає збій, то код Win32 перевіряє,  чи не належить даний процес  до іншої підсистемі (наприклад, WOW64). Або, можливо, дана програма  позначена для виконання під  управлінням відладчика. Ці спеціальні випадки обробляються спеціальним кодом користувацького режиму в CreateProcess.

15. Якщо NtCreateUserProcess відпрацював успішно, то процеси Win32 потрібно зареєструвати в процесі csrss.exe підсистеми Win32. Kernel32.dll посилає повідомлення в csrss, яке повідомляє йому про новий процес (а також передає описувачі процесу і потоку, щоб він міг себе дублювати). Процеси і потоки вносяться в таблиці підсистеми (щоб там був повний список всіх процесів і потоків Win32). Потім підсистема показує курсор (вказівник з пісочним годинником), щоб повідомити користувачеві про те, що в даний момент щось відбувається, але курсор все ж можна використовувати. Коли процес робить свій перший виклик графічного інтерфейсу користувача (зазвичай це робиться для створення вікна), то курсор зникає (якщо немає інших викликів) - тайм-аут у нього 2 с.

16. Якщо процес обмежений  (як має низькі права Internet Explorer), то маркер модифікується для  обмеження доступу до об'єктів  з нового процесу.

17. Якщо додаток було  помічено як підлягаючий виправленню (shimmed) для сумісної роботи в поточній версії Windows, то застосовуються зазначені виправлення (shims). Виправлення зазвичай укладають в оболонку виклики бібліотек, щоб модифікувати їх поведінку - наприклад, повернути сфальсифікований номер версії або відкласти звільнення пам'яті.

18. І нарешті, виклик  NtResumeThread для скасування призупинення потоку і повернення викликала стороні структури, що містить ідентифікатори та описувачі для щойно створених процесу і потоку.

1.3.3. Планування

Ядро Windows не має центрального потоку планування. Замість цього  (коли потік не може більше виконуватися) потік входить в режим ядра і викликає планувальник, щоб побачити, на якій потік слід перемкнутися. До виконання поточним потоком коду планувальника призводять такі умови:

1. Поточний виконуючий потік блокується на семафорі, мьютекс, події, введенні-виведенні і т. д.

2. Потік сигналізує об'єкт  (тобто робить up на семафорі або призводить до сигналізування події).

3. Закінчується квант.

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

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

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

Планувальник викликається також в двох інших випадках: завершується операція введення-виведення; закінчується час очікування.

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

Якщо протягом цього тайм-ауту потік став готовим, то буде виконаний  планувальник, і якщо новий готовий  до виконання потік має більш  високий пріоритет, то поточний потік  витісняється (як у випадку 1).

Тепер розглянемо сам алгоритм планування. Інтерфейс Win32 API надає два API для роботи з плануванням потоків. Перший - виклик SetPriorityClass, який встановлює клас пріоритету для всіх потоків викликає процесу. Допустимі значення: real-time, high, above normal, normal і idle. Клас пріоритету визначає відносний пріоритет процесу. (Починаючи з Windows Vista клас пріоритету процесу може також використовуватися процесом для того, щоб тимчасово помітити самого себе як фоновий - це означає, що він не повинен заважати ніякої іншої активності системи.) Клас пріоритету встановлюється для процесу, але впливає на реальний пріоритет кожного потоку процесу (він встановлює базове значення пріоритету, з яким стартує потік при створенні).

Другий інтерфейс Win32 API - це SetThreadPriority. Він встановлює відносний пріоритет потоку (можливо, викликаючого потоку - але це не обов'язково) по відношенню до класу пріоритету свого процесу. Допустимі значення: time critical, highest, above normal, normal, below normal, lowest і idle. Потоки time critical отримують найвищий пріоритет планування, а потоки idle - найнижчий (незалежно від класу пріоритету). Інші значення пріоритету підлаштовують базовий пріоритет потоку відносно нормального значення, визначеного класом пріоритету (+2, +1, 0, -1, -2 відповідно). Використання класів пріоритету і відносних пріоритетів потоків полегшує додаткам прийняття рішень за вказівкою пріоритетів.

Планувальник працює таким  чином. В системі є 32 пріоритету з  номерами від 0 до 31. Поєднання класу  пріоритету і відносного пріоритету відображається на 32 абсолютних значення пріоритету (відповідно до табл. 1). Номер  у таблиці визначає базовий пріоритет (base priority) потоку. Крім того, кожен потік має поточний пріоритет (current priority), який може бути вище (але не нижче) базового пріоритету.

Таблиця 1.Відповідність пріоритетів Win32 пріоритетам Windows

Для використання цих пріоритетів  при плануванні система підтримує  масив з 32 списків потоків, які  відповідають усім 32 пріоритетам (від 0 до 31) в табл. 1. Кожен список містить готові потоки відповідного пріоритету. Базовий алгоритм планування робить пошук по масиву від пріоритету 31 до пріоритету 0. Як тільки буде знайдений вільний список, то вибирається потік з верху списку і виконується протягом одного кванта. Якщо квант закінчується, то потік переводиться в кінець черги свого рівня пріоритету і наступним вибирається потік з верху списку. Інакше кажучи, коли є багато готових потоків на найвищому рівні пріоритету, то вони виконуються циклічно (по одному кванту часу кожен). Якщо готових потоків немає, то процесор переходить в стан очікування, тобто переводиться в стан більш низького енергоспоживання і чекає переривання.

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

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

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

Рис. 1.3.3.1. Windows Vista підтримує 32 пріоритети для потоку

Масив заголовків черг показаний на рис. 1.3.3.1. На схемі показано, що реально є чотири категорії пріоритетів: real-time, user, zero і idle (значення якого фактично дорівнює -1). Це вимагає особливого пояснення. Пріоритети 16-31 називаються пріоритетами реального часу і призначені для створення систем, що задовольняють обмеженням реального часу (таким, як кінцеві терміни). Потоки з пріоритетами реального часу виконуються до потоків з динамічними пріоритетами (але не раніше DPC та ISR). Якщо додаток реального часу хоче виконуватися в системі, то йому можуть знадобитися такі драйвери пристроїв, які не мають тривалого виконання DPC або ISR (оскільки це може викликати пропуск потоками реального часу їх кінцевих термінів).

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

Потоки додатків зазвичай виконуються з пріоритетами 1-15. За допомогою установки пріоритетів  процесів і потоків додаток може визначити, які потоки отримують  перевагу. Системні потоки обнулення сторінок (ZeroPage) працюють з пріоритетом 0 і перетворять вільні сторінки в заповнені нулями сторінки. Для кожного реального процесора є окремий потік обнулення сторінок.

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

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

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

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