Устройство Windows. Планирование потоков

Приоритетная вытесняющая система планирования

В Windows реализована приоритетная вытесняющая система планирования, при которой всегда выполняется хотя бы один поток с самым высоким приоритетом. По умолчанию потоки могут запускаться только на доступном процессоре (ядре) из связанной с процессом группы процессоров. То есть Windows (если в системе много процессоров и ядер) делит все ядра на группы по 64 ядра и каждому процессу дается доступ только к определенной группе, и потоки этого процесса могут обращаться только к этой группе ядер.

После того как поток был выбран на исполнение процессором, он запускается на время, называемое квантом. Время кванта может зависеть от настроек системы, бывают длинные или короткие кванты.

Но поток может не отработать весь свой квант, так как в Windows реализована вытесняющая многозадачность, это означает что если другой поток готов к выполнению и имеет более высокий приоритет, то он вытеснит первый процесс.

Планировщик который занимается всем этим планированием потоков работает в режиме ядра, при этом код планировщика разбросан по ядру (нет определенного единого модуля). А вот эти все процедуры которые разбросаны по ядру, но связанные с планированием потоков называют диспетчером ядра.

Ядро процессора каждый раз когда обрабатывает новый поток переключает контекст — сохраняет состояние предыдущего потока и запускает новый поток.

Windows осуществляет планирование потоков на уровне потоков. Например, если процесс А имеет 10 потоков, а процесс Б имеет 2 потока, то все 12 потоков имеют одинаковый приоритет. Windows не поделит процессорное время по 50% между процессом А и Б.

Приоритеты потоков

Windows использует 32 уровня приоритета от 0 до 31 (31 наивысший):

• 16 — 31 — уровни реального времени,
• 1 — 15 — обычные динамические приоритеты,
• 0 — зарезервирован для потока обнуления страниц.

Поток получает свой уровень вначале из Windows API, это базовый приоритет (он наследуется от приоритета процесса):

• реального времени (24),
• высокий (13),
• выше среднего (10),
• обычный (8),
• ниже среднего (6),
• низкий (4).

Дальше назначается относительный приоритет который увеличивает или уменьшает приоритет потока:

• критический по времени (+15),
• наивысший (+2),
• выше среднего(+1),
• обычный (0),
• ниже среднего (-1),
• самый низкий (-2),
• уровень простоя (-15).

После получения базового приоритета и корректировки относительным приоритетом получается динамический приоритет:

Изменить базовый приоритет процесса можно из диспетчера задач на вкладке «Подробности» (или в Process Explorer):

При этом относительные приоритеты не меняются.

Следует иметь в виду что многие важные системные потоки выполняемые в режиме ядра работают в диапазоне приоритетов реального времени. Если поток слишком долго выполняется в режиме реального времени, то он блокирует процессор для других важных потоков, что может привести к ошибкам и зависаниям.

Приоритеты отдельных потоков можно посмотреть в программе «Process Explorer», однако если и есть смысл изменять приоритеты процессов обычному пользователю, то настраивать приоритеты потокам нет смысла, так как только разработчик данной программы понимает как расставить приоритеты потокам.

Запустить программу с определенным приоритетом можно из командной строки используя команду start:

А еще можно сделать такой ярлык:

Этот ярлык сразу будет запускать блокнот с низким приоритетом.

А теперь посмотрим на приоритет потока:

Это означает что мы запустили процесс с низким приоритетом (4) но поток внутри процесса имеет относительный приоритет «Наивысший (+2)» и поток получил динамический приоритет 6.

Получается что приоритет потока Notepad.exe всегда будет выше на 2 (при работе на переднем плане, в фоне приоритет упадет):

• На низком будет 6
• Ниже среднего — 8
• Обычный — 10
• Выше среднего — 12
• Высокий — 15

А вот в режиме реального времени ядро не применяет относительные приоритеты для потоков, поэтому:

Состояния потоков

Поток может находиться в следующих состояниях:

• Готов (Ready) — поток готов к выполнению и ожидает процессор.
• Готов с отложенным выполнением (Deferred ready) — поток выбран для выполнения на конкретном ядре и ожидает именно это ядро.
• В повышенной готовности (Standby) — поток выбран следующим для выполнения на конкретном ядре. Как только сможет процессор выполнит переключение контекста на этот поток.
• Выполнение (Running) — выполняется на процессоре пока не истечет его квант времени, или пока его не вытеснит поток с большем приоритетом.
• Ожидание (Waiting) — поток ждет каких-то ресурсов.
• Переходное состояние (Transition) — готов к выполнению, но стек ядра выгружен из памяти, как только стек загрузится в память поток перейдет в состояние Готов.
• Завершение (Terminated) — поток выполнил свою работу и завершился сам, или его завершили принудительно.
• Инициализация (Initializated) — состояние при создании потока.

Кванты времени

Квант времени может быть длинным или коротким. В настольных системах по умолчанию квант времени короткий, чтобы различные приложения быстро уступали друг другу место. В серверных системах по умолчанию длинный квант времени, чтобы серверные службы реже переключали контекст процессора.

Если зайти в «Свойства системы» / «Дополнительные параметры системы» / «Дополнительно» / «Быстродействие» / «Параметры» / «Дополнительно»:

Вот эта оптимизация и управляет квантом времени.

На серверной системе можно выставить «программ» если это сервер терминалов или просто настольный компьютер с серверной системой.

На десктопной системе можно выбрать «служб» если вы запускаете какую-то длительную компиляцию или рендерите видео и т.п, а потом вернуть обратно в состояние «программ».

Изменение приоритета планировщиком

Планировщик Windows периодически меняет текущий приоритет потоков. Делается это например для:

• повышение приоритета если готовый поток слишком долго ожидает выполнения (предотвращает зависание программы);
• повышение приоритета если происходит ввод из пользовательского интерфейса (сокращение времени отклика);
• повышение приоритета после завершения операции ввода/вывода (чтобы потоки ждущие ввод/вывод быстрее выполнялись). При этом если ожидается диск, cd-rom, параллельный порт, видео — повышение на 1 пункт. Если ожидается сеть, почтовый слот, именованный канал, последовательный порт — повышение на 2 пункта. Если ожидается клавиатура или мышь — повышение на 6 пунктов. Если ожидается звуковая карта — повышение на 8 пунктов;
• когда поток ожидает ресурс, который занят другим потоком, то система может повысить приоритет потока который занял нужный ресурс, чтобы он быстрее выполнил свою работу и освободил этот ресурс;
• повышается приоритет у потоков которые на первом плане, а фоновые потоки работают с низким приоритетом.

Эксперимент — изменение приоритетов планировщиком

Следующий эксперимент покажет как посмотреть за повышением и понижением динамического приоритета:

1. Запустите программу «Блокнот».
2. Запустите «Системный монитор».
3. Щелкните на кнопке панели инструментов «Добавить» (Add Counter).
4. Выберите объект «Поток» (Thread), а затем выберите счетчик «Текущий приоритет» (Priority Current).
5. В поле со списком введите «Notepad», а затем щелкните на кнопке «Поиск» (Search).
6. Найдите строку «Notepad/О». Выберите ее, щелкните на кнопке «Добавить» (Add), а затем щелкните на кнопке «ОК».
7. Как только вы щелкните мышкой по блокноту, то заметите в Системном мониторе, что приоритет у потока «Блокнот» поднялся до 12, если свернуть блокнот то приоритет вновь упадет до 10.

Поток простоя — idle

Когда у процессорного ядра нет потоков, то на нем запускается специальный поток idle (поток простоя). У каждого ядра есть свой собственный поток простоя. Все потоки простоя принадлежат процессу простоя. Поток простоя имеет самый низкий приоритет (1), поэтому выполняется только тогда — когда полезных потоков нет.

В диспетчере задач можно не только задавать приоритет, но и задавать сходство. При задания сходства можно выбрать определенные ядра процессора, на которых будут выполнятся потоки данного процесса. Если так настроить один процесс, то все его дочерние процессы также будут работать с этим списком ядер процессора. Таким образом сходство процессора лучше не ограничивать, чтобы система сама определяло лучшее (свободное) ядро для выполнения потоков.

Групповое планирование

Планирование потоков на базе потоков отлично работает, но не способно решить задачу равномерного распределения процессорного времени между несколькими пользователями на терминальном сервере. Поэтому в Windows Server 2012 появился механизм группового планирования.

Несколько терминов, относящихся к групповому планированию:

• Поколение — период времени, в течении которого отслеживается использование процессора.
• Квота — процессорное время, разрешенное группе на поколение. Исчерпание квоты означает, что группа израсходовала весь свой бюджет.
• Вес — относительная важность группы от 1 до 9 (по умолчанию 5).
• Справедливое долевое планирование — вид планирования, при котором потокам исчерпавшим квоту могут выделяться циклы простоя.
• Ранг — приоритет групповой политики, 0 — наивысший, чем больше процессорного времени истратила группа, тем больше будет ранг, и с меньшей вероятностью получит процессорное время. Ранг всегда превосходит приоритет. 0 ранг у потоков которые: не входят ни в одну группу, не израсходовали квоту, потоки с приоритетами реального времени.

Механизм DFSS используется для справедливого распределения процессорного времени между сеансами на машине. Этот механизм включается по умолчанию при установке роли служб терминалов.

Помимо DFSS групповое планирование применяется в объектах Jobs (Задания), так мы можем ограничить Задание по % потребления CPU, например задание будет потреблять не больше 20% процессорного времени.

• Узнали что в Windows реализована приоритетная вытесняющая система планирования.
• Познакомились с квантами времени, бывают короткие и длинные кванты. Узнали как можно управлять квантами.
• Посмотрели на приоритеты потоков: есть базовый, относительный и динамический приоритеты.
• Узнали в каких состояниях могут находится потоки.
• Познакомились с потоком простоя — idle.
• А также познакомились с групповым планированием.

Оглавление курса доступно по ссылке.

Кванты для потоков windows

B однопроцессорных системах база данных диспетчера ядра синхронизируется повышением IRQL до уровня «DPC/dispatch» и SYNCH_LEVEL (оба определены как уровень 2). (Об уровнях приоритета прерываний см. раздел «Диспетчеризация ловушек» главы 3) Такое повышение IRQL не дает другим потокам прервать диспетчеризацию потоков, так как потоки обычно выполняются при IRQL O или 1. B многопроцессорных системах одного повышения IRQL мало, потому что каждый процессор может одновременно увеличить IRQL до одного уровня и попытаться обратиться к базе данных диспетчера ядра. Как Windows синхронизирует доступ к этой базе данных в многопроцессорных системах, поясняется в разделе «Многопроцессорные системы» далее в этой главе.

Квант

Как уже говорилось, квант – это интервал процессорного времени, отведенный потоку для выполнения. По его окончании Windows проверяет, ожидает ли выполнения другой поток с таким же уровнем приоритета. Если на момент истечения кванта других потоков с тем же уровнем приоритета нет, Windows выделяет текущему потоку еще один квант.
По умолчанию в Windows 2000 Professional и Windows XP потоки выполняются в течение 2 интервалов таймера (clock intervals), а в системах Windows Server – 12. (Как изменить эти значения, мы объясним позже.) B серверных системах величина кванта увеличена для того, чтобы свести к минимуму переключение контекста. Получая больший квант, серверные приложения, которые пробуждаются при получении клиентского запроса, имеют больше шансов выполнить запрос и вернуться в состояние ожидания до истечения выделенного кванта.
Длительность интервала таймера зависит от аппаратной платформы и определяется HAL, а не ядром. Например, этот интервал на большинстве однопроцессорных х8б-систем составляет 10 мс, а на большинстве многопроцессорных х8б-систем – около 15 мс. (Как проверить реальный интервал системного таймера, см. в следующем эксперименте.)

ЭКСПЕРИМЕНТ: определяем величину интервала системного таймера
Windows-функция GetSystemTimeAdjustmentвозвращает величину интервала системного таймера. Для ее определения запустите программу Clockres с sysinternals.com .Вот что это программа выводит на однопроцессорной х86-системе:

The system clock interval is 10.014400 ms

Учет квантов времени

Величина кванта для каждого процесса хранится в блоке процесса ядра. Это значение используется, когда потоку предоставляется новый квант. Когда поток выполняется, его квант уменьшается по истечении каждого интервала таймера, и в конечном счете срабатывает алгоритм обработки завершения кванта. Если имеется другой поток с тем же приоритетом, ожидающий выполнения, происходит переключение контекста на следующий поток в очереди готовых потоков. Заметьте: когда системный таймер прерывает DPC или процедуру обработки другого прерывания, квант выполнявшегося потока все равно уменьшается, даже если этот поток не успел отработать полный интервал таймера. Если бы это было не так и если бы аппаратное прерывание или DPC появилось непосредственно перед прерыванием таймера, квант потока мог бы вообще никогда не уменьшиться.
Внутренне величина кванта хранится как число тактов таймера, умноженное на 3. To есть в Windows 2000 и Windows XP потоки по умолчанию получают квант величиной 6 (2 * 3), в Windows Server – 36 (12 * 3). Всякий раз, когда возникает прерывание таймера, процедура его обработки вычитает из кванта потока постоянную величину (3).
Почему квант внутренне хранится как величина, кратная трем квантовым единицам за один такт системного таймера? Это сделано для того, чтобы можно было уменьшать значение кванта по завершении ожидания. Когда поток с текущим приоритетом ниже 16 и базовым приоритетом ниже 14 запускает функцию ожидания (WaitForSingleObjectили WaitForMultipleObjects)и его запрос на доступ удовлетворяется немедленно (например, он не переходит в состояние ожидания), его квант уменьшается на одну единицу. Благодаря этому кванты ожидающих потоков в конечном счете заканчиваются.
Если запрос на доступ не удовлетворяется немедленно, кванты потоков с приоритетом ниже 16 тоже уменьшаются на одну единицу (кроме случая, когда поток пробуждается для выполнения APC ядра). Ho перед такой операцией квант потока с приоритетом 14 или выше сбрасывается. Это делается и для потоков с приоритетом менее 14, если они не выполняются при специально повышенном приоритете (как, например, в случае фоновых процессов или при недостаточном выделении процессорного времени) и если их приоритет повышен в результате выхода из состояния ожидания (unwait operation). (Динамическое повышение приоритета поясняется в следующем разделе.)

Управление величиной кванта

Вы можете изменить квант для потоков всех процессов, но выбор ограничен всего двумя значениями: короткий квант (2 такта таймера, используется по умолчанию для клиентских компьютеров) или длинный (12 тактов таймера, используется по умолчанию для серверных систем).

ПРИМЕЧАНИЕ Используя объект «задание» в системе с длинными квантами, вы можете указать другие величины квантов для процессов в задании. Более подробную информацию об объектах «задание» см. в разделе «Объекты-задания» далее в этой главе.

Для изменения величины кванта в Windows 2000 щелкните правой кнопкой мыши My Computer (Мой компьютер), выберите Properties (Свойства), перейдите на вкладку Advanced (Дополнительно), а затем щелкните кнопку Performance Options (Параметры быстродействия). Вы увидите диалоговое окно, показанное на рис. 6-l6.

Параметр Programs (Программ), который в Windows 2000 назывался Applications (Приложений), соответствует использованию коротких квантов переменной величины – этот вариант действует для Windows 2000 Professional и Windows XP по умолчанию. Если вы установите Terminal Services в систему Windows Server и настроите ее как сервер приложений, то и в такой системе будет выбран именно этот параметр, чтобы пользователи сервера терминала получали одинаковые кванты, как и в клиентских или персональных системах. Работая с Windows Server как с персональной операционной системой, вы также могли бы вручную выбрать этот параметр.
Параметр Background Services (Фоновых служб) подразумевает применение длинных квантов фиксированного размера, что предлагается по умолчанию в системах Windows Server. Единственная причина, по которой имело бы смысл выбрать этот параметр на рабочей станции, – ее использование в качестве серверной системы.
Еще одно различие между параметрами Programs и Background Services заключается в том, какой эффект они оказывают на кванты потоков в активном процессе. Об этом рассказывается в следующем разделе.

Динамическое увеличение кванта

До Windows NT 4.0, когда на рабочей станции или в клиентской системе какое-то окно становилось активным, приоритет всех потоков активного процесса (которому принадлежит поток, владеющий окном в фокусе ввода) динамически повышался на 2. Повышенный приоритет действовал до тех пор, пока любому потоку процесса принадлежало активное окно. Проблема с этим подходом была в том, что, если вы запустили длительный процесс, интенсивно использующий процессор (например, начали пересчет электронной таблицы), и переключились на другой процесс, требующий больших вычислительных ресурсов (скажем, на одну из программ CAD, графический редактор или какую-нибудь игру), то первый процесс, ставший теперь фоновым, получит лишь очень малую часть процессорного времени (или вообще не получит его). A все дело в том, что приоритет потоков активного процесса повышается на 2 (здесь предполагается, что базовый приоритет потоков обоих процессов был одинаковым).
Это поведение по умолчанию изменилось с появлением Windows NT 4.0 Workstation – кванты потоков активного процесса стали увеличиваться в 3 раза. Таким образом, по умолчанию на рабочих станциях их квант достигал 6 тактов таймера, а у потоков остальных процессов – 2 тактов. Благодаря этому, когда процесс, интенсивно использующий процессорные ресурсы, оказывается фоновым, новый активный процесс получает пропорционально большее процессорное время (и вновь предполагается, что приоритеты потоков одинаковы как в активном, так и в фоновом процессе).
Заметьте, что это изменение квантов относится лишь к процессам с приоритетом выше IdIe в системах с установленным параметром Programs (или Applications в Windows 2000) в диалоговом окне Performance Options (Параметры быстродействия), как пояснялось в предыдущем разделе. Кванты потоков активного процесса в системах с установленным параметром Background Services (настройка по умолчанию в системах Windows Server) не изменяются.

Параметр реестра для настройки кванта

(o) Короткие или длинныеЗначение 1 указывает на длинные кванты, а 2 – на короткие. Если это поле равно 0 или 3, используются кванты по умолчанию (короткие в Windows 2000 Professional или Windows XP и длинные в системах Windows Server).
(o) Переменные или фиксированныеЕсли задано значение 1, кванты потоков активного процесса могут варьироваться, а если задано значение 2 – нет. Если это поле равно 0 или 3, используется настройка по умолчанию (переменные в Windows 2000 Professional или Windows XP и фиксированные в системах Windows Server).
(o) Динамическое приращение кванта потока активного процессаЭто поле (хранящееся в переменной ядра PsPrioritySeparatiori)может быть равно 0, 1 или 2 (значение 3 недопустимо и интерпретируется как 2) и представляет собой индекс в трехэлементном байтовом массиве (PspForegroundQuantum),используемом для расчета квантов потоков активного процесса. Кванты потоков фоновых процессов определяются первым элементом этого массива. Возможные значения в PspForegroundQuantumперечислены в таблице 6-l6.

Заметьте, что при использовании диалогового окна Performance Options (Параметры быстродействия) доступны лишь две комбинации: короткие кванты с утроением в активном процессе или длинные без изменения в таком процессе. Ho прямое редактирование параметра Win32PrioritySeparation в реестре позволяет выбирать и другие комбинации.

Сценарии планирования

Известно, что вопрос «Какому потоку отдать процессорное время?» Windows 2000 решает, исходя из приоритетов. Ho как этот подход работает на практике? Следующие разделы иллюстрируют, как вытесняющая многозадачность, управляемая на основе приоритетов, действует на уровне потоков.

Самостоятельное переключение

Ha рис. 6-19 поток (верхний блок) самостоятельно освобождает процессор, в результате чего к процессору подключается другой поток из очереди (отмеченный кольцом в колонке Running). Исходя из этой схемы, можно подумать, что приоритет потока, освобождающего процессор, снижается, но это не так – он просто переводится в очередь ожидания выбранных им объектов. A что происходит с оставшейся частью кванта этого потока? Когда поток входит в состояние ожидания, квант не сбрасывается. Как уже говорилось, после успешного завершения ожидания квант потока уменьшается на одну единицу, что эквивалентно трети интервала таймера (исключение составляют потоки с приоритетом от 14 и выше, у которых после ожидания квант сбрасывается).

Вытеснение

B этом сценарии поток с более низким приоритетом вытесняется готовым к выполнению потоком с более высоким приоритетом. Такая ситуация может быть следствием двух обстоятельств:
(o)завершилось ожидание потока с более высоким приоритетом (т. е. произошло событие, которого он ждал);
(o)приоритет потока увеличился или уменьшился.
B любом из этих случаев Windows решает, продолжить выполнение текущего потока или вытеснить его потоком с более высоким приоритетом.

ПРИМЕЧАНИЕ Потоки пользовательского режима могут вытеснять потоки режима ядра. To есть режим выполнения потока значения не имеет – определяющим фактором является его приоритет.

Когда поток вытесняется, он помещается в начало очереди готовых потоков соответствующего уровня приоритета. Эту ситуацию иллюстрирует рис. 6-20.

Ha рис. 6-20 поток с приоритетом 18 выходит из состояния ожидания и вновь захватывает процессор, вытесняя выполняемый в этот момент поток (с приоритетом 16) в очередь готовых потоков. Заметьте, что вытесненный поток помещается не в конец, а в начало очереди. После завершения вытеснившего потока вытесненный сможет отработать остаток своего кванта.

Завершение кванта

Завершение потока

Завершаясь (после возврата из основной процедуры и вызова ExitThreadили из-за уничтожения вызовом TerminateThread),поток переходит в состояние Terminated. Если в этот момент ни один описатель его объекта «поток» не открыт, поток удаляется из списка потоков процесса, и соответствующие структуры данных освобождаются.

Переключение контекста

Контекст потока и процедура его переключения зависят от архитектуры процессора. B типичном случае переключение контекста требует сохранения и восстановления следующих данных:
(o)указателя команд;
(o)указателей на стек ядра и пользовательский стек;
(o)указателя на адресное пространство, в котором выполняется поток (каталог таблиц страниц процесса).

Ядро сохраняет эту информацию, заталкивая ее в текущий стек ядра, обновляя указатель стека и сохраняя его в блоке KTHREAD потока. Далее указатель стека ядра устанавливается на стек ядра нового потока и загружается контекст этого потока. Если новый поток принадлежит другому процессу, в специальный регистр процессора загружается адрес его каталога таблиц страниц, в результате чего адресное пространство этого процесса становится доступным (о трансляции адресов см. в главе 7). При наличии отложенной APC ядра запрашивается прерывание IRQL уровня 1. B ином случае управление передается загруженному для нового потока указателю команд, и выполнение этого потока возобновляется.

Поток простоя

Если нет ни одного потока, готового к выполнению на процессоре, Windows подключает к данному процессору поток простоя (процесса Idle). Для каждого процессора создается свой поток простоя.
Разные утилиты для просмотра процессов в Windows по-разному называют процесс Idle. Диспетчер задач и Process Explorer обозначают его как «System Idle Process», Process Viewer – как «Idle», Pstat – как «Idle Process», Process Explode и Tlist – как «System Process», a Qslice – как «SystemProcess». Windows сообщает, что приоритет потока простоя равен 0. Ho на самом деле у него вообще нет уровня приоритета, поскольку он выполняется лишь в отсутствие других потоков. (Вспомните, что на нулевом уровне приоритета в Windows работает лишь поток обнуления страниц; см. главу 7.)
Холостой цикл, работающий при IRQL уровня «DPC/dispatch», просто запрашивает задания, например на доставку отложенных DPC или на поиск потоков, подлежащих диспетчеризации.

Хотя последовательность работы потока простоя зависит от архитектуры, он все равно выполняет следующие действия.
1. Включает и отключает прерывания (тем самым давая возможность доставить отложенные прерывания).
2. Проверяет, нет ли у процессора незавершенных DPC (см. главу 3). Если таковые есть, сбрасывает отложенное программное прерывание и доставляет эти DPC
3. Проверяет, выбран ли какой-нибудь поток для выполнения на данном процессоре, и, если да, организует его диспетчеризацию.
4. Вызывает из HAL процедуру обработки процессора в простое (если нужно выполнить какие-либо функции управления электропитанием).

B Windows Server 2003 поток простоя также проверяет наличие потоков, ожидающих выполнения на других процессорах, но об этом пойдет речь в разделе по планированию потоков в многопроцессорных системах.

Динамическое повышение приоритета

Windows может динамически повышать значение текущего приоритета потока в одном из пяти случаев:
(o)после завершения операций ввода-вывода;
(o)по окончании ожидания на событии или семафоре исполнительной системы;
(o)по окончании операции ожидания потоками активного процесса;
(o)при пробуждении GUI-потоков из-за операций с окнами;
(o)если поток, готовый к выполнению, задерживается из-за нехватки процессорного времени.

Динамическое повышение приоритета предназначено для оптимизации общей пропускной способности и отзывчивости системы, а также для устранения потенциально «нечестных» сценариев планирования. Однако, как и любой другой алгоритм планирования, динамическое повышение приоритета – не панацея, и от него выигрывают не все приложения.

ПРИМЕЧАНИЕ Windows никогда не увеличивает приоритет потоков в диапазоне реального времени (16-31). Поэтому планирование таких потоков по отношению к другим всегда предсказуемо. Windows считает: тот, кто использует приоритеты реального времени, знает, что делает.

Динамическое повышение приоритета после завершения ввода-вывода

Как уже отмечалось, динамическое повышение приоритета применяется только к потокам с приоритетом динамического диапазона (0-15). Независимо от приращения приоритет потока никогда не будет больше 15. Иначе говоря, если к потоку с приоритетом 14 применить динамическое повышение на 5 уровней, его приоритет возрастет лишь до 15. Если приоритет потока равен 15, он остается неизменным при любой попытке его повышения.

Динамическое повышение приоритета по окончании ожидания событий и семафоров

Когда ожидание потока на событии исполнительной системы или объекте «семафор» успешно завершается (из-за вызова SetEvent, PulseEventили ReleaseSemaphore),его приоритет повышается на 1 уровень (см. значения EVENT_INCREMENT и SEMAPHORE_INCREMENT в заголовочных файлах DDK). Причина повышения приоритета потоков, закончивших ожидание событий или семафоров, та же, что и для потоков, ожидавших окончания операций ввода-вывода: потокам, блокируемым на событиях, процессорное время требуется реже, чем остальным. Такая регулировка позволяет равномернее распределять процессорное время.
B данном случае действуют те же правила динамического повышения приоритета, что и при завершении операций ввода-вывода (см. предыдущий раздел).
K потокам, которые пробуждаются в результате установки события вызовом специальных функций NtSetEventBoostPriority(используется в Ntdll.dll для критических секций) и KeSetEventBoostPriority(используется для ресурсов исполнительной системы и блокировок с заталкиванием указателя) повышение приоритета применяется особым образом. Если поток с приоритетом 13 или ниже, ждущий на событии, пробуждается в результате вызова специальной функции, его приоритет повышается до приоритета потока, установившего событие, плюс 1. Если длительность его кванта меньше 4 единиц, она приравнивается 4 единицам. Исходный приоритет восстанавливается по истечении этого кванта.

Динамическое повышение приоритета потоков активного процесса после выхода из состояния ожидания

Всякий раз, когда поток в активном процессе завершает ожидание на объекте ядра, функция ядра KiUnwaitThreadдинамически повышает его текущий (не базовый) приоритет на величину текущего значения PsPrioritySeparation.(Какой процесс является активным, определяет подсистема управления окнами.) Как было сказано в разделе «Управление величиной кванта» ранее в этой главе, PsPrioritySeparationпредставляет собой индекс в таблице квантов (байтовом массиве), с помощью которой выбираются величины квантов для потоков активных процессов. Однако в данном случае PsPrioritySeparationиспользуется как значение, на которое повышается приоритет.
Это увеличивает отзывчивость интерактивного приложения по окончании ожидания. B результате повышаются шансы на немедленное возобновление его потока – особенно если в фоновом режиме выполняется несколько процессов с тем же базовым приоритетом.
B отличие от других видов динамического повышения приоритета этот поддерживается всеми системами Windows, и его нельзяотключить даже через Windows-функцию SetThreadPriorityBoost.