Преобразование приоритетов Win32 в приоритеты Windows 2000

Приоритеты потоков Win32	Классы приоритетов процессов в Win32				Ниже нормы	Бездействующий
	Реального времени	Высокий	Выше нормы	Нормальный
	31	15	15	15	15	15
Самый высокий	26	15	12	10	8	6
Выше нормы	25	14	11	9	7	5
Приоритеты потоков Win 32	Классы приоритетов процессов в ghbjhbntnjd ghjwtccjd d Цшт 32				Ниже нормы	Бездействующий
	Реального времени	Высокий	Выше нормы	Нормальный
Критичный ко времени	31	15	15	15	15	15
Самый высокий	26	15	12	10	8	6
Выше нормы	25	14	11	9	7	5
Нормальный	24	13	10	8	6	4
Ниже нормы	23	12	9	7	5	3
Самый низкий	22	11	8	6	4	2
Неработающий	16	1	1	1	1	1

При планировании не учитывается, какому процессу принадлежит тот или иной поток. То есть планировщик не выбирает сначала процесс, а затем поток в этом процессе. Он смотрит только на потоки. Он даже не знает, какой поток какому процессу принадлежит. На многопроцессорной системе каждый центральный процессор сам занимается планированием своих потоков при помощи массива приоритетов. Чтобы гарантировать, что в каждый момент времени лишь один центральный процессор работает с массивом, используется спин-блокировка.

Массив заголовков очередей показан на рис. 2. Из рисунка видно, что в действительности существует четыре категории приоритетов: реального времени, пользовательские, нулевой и бездействующий, равный -1. Приоритеты с 16 по 31 называются приоритетами реального времени, но они таковыми не являются. Выполняющимся с этими приоритетами потокам не дается никаких гарантий и никакие сроки исполнения не учитываются. Это просто более высокие приоритеты, чем приоритеты с 0 по 15. Однако приоритеты с 16 по 31 зарезервированы для самой системы и для потоков, которым такой высокий приоритет явно задаст системный администратор. Обычные пользователи не могут запускать потоки со столь высокими приоритетами, и существует веская причина для этого. Если бы пользовательский процесс мог работать с приоритетом более высоким, чем, скажем, поток клавиатуры или мыши, то длительная работа такого высокоприоритетного потока без операций ввода-вывода (например, в цикле) повесила бы всю систему.

Рис. 2. Windows 2000 поддерживает 32 приоритета для потоков

Пользовательские потоки работают с приоритетами от 1 до 15. Устанавливая приоритеты процесса и потока, пользователь может отдавать преимущество тому или иному потоку. Нулевой поток работает в фоновом режиме и съедает все процессорное время, на которое больше никто не претендует. Его работа заключается в обнулении страниц для менеджера памяти. Его роль в системе будет обсуждаться ниже. Если и у этого потока нет работы, работает пустой поток. Однако он не является полноценным потоком.

Со временем для улучшения производительности системы в базовом алгоритме планирования было сделано несколько усовершенствований. При определенных условиях текущий приоритет пользовательского потока может быть поднят операционной системой выше базового приоритета, но никогда не может быть установлен выше приоритета 15. Так как массив на рис. 2 основан на текущем приоритете, изменение этого приоритета изменяет поведение алгоритма планирования. Для потоков с приоритетами 15 и выше никогда не делается никаких изменений приоритета.

Приоритет потока увеличивается:

1. Когда завершается операция ввода-вывода и освобождает ожидающий ее поток, приоритет потока увеличивается, чтобы дать шанс этому потоку быстрее запуститься и снова запустить операцию ввода-вывода. Величина, на которую увеличивается приоритет, зависит от устройства ввода-вывода. Как правило, это 1 для диска, 2 для последовательной линии, 6 для клавиатуры и 8 для звуковой карты.

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

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

Есть еще один случай, при котором система изменяет приоритеты потоков. Два потока работают вместе в задаче типа «производитель-потребитель». Работа производителя труднее, поэтому он получает более высокий приоритет, например 12, а потребитель получает приоритет 4. В определенный момент производитель заполняет до отказа общий буфер и блокируется на семафоре, как показано на рис. 3, а.

Рис. 3. Пример инверсии приоритета

Прежде чем потребитель снова получит шанс поработать, посторонний процесс с приоритетом 8 приходит в состояние готовности и получает управление, (рис. 3, б). Этот поток сможет работать столько, сколько захочет, так как его приоритет выше приоритета потребителя, а производитель, хоть и с большим приоритетом, заблокирован. При таких условиях производитель никогда снова не получит управления, пока поток с приоритетом 8 не остановится.

Операционная система Windows 2000 следит, сколько времени прошло с тех пор, когда готовый к работе поток запускался в последний раз. Если какой-либо поток превысит определенный интервал времени, он получает на два кванта времени приоритет 15. Это может помочь разблокировать производителя. После двух квантов прибавка приоритета резко убирается. Вероятно, лучшим решением было бы наказывать потоки, которые полностью используют свои кванты снова и снова. В конце концов, проблему создает не поток, умирающий от голода, а жадный поток. Эта проблема хорошо известна под названием инверсии приоритетов.

Аналогичная проблема возникает в том случае, когда поток с приоритетом 16 захватывает мьютекс и долго не получает управления, в результате чего более важные системные потоки, ждущие этого мьютекса, умирают от истощения. Эту проблему можно устранить, если разрешить потоку, которому на короткое время требуется мьютекс, просто запрещать планирование на время использования мьютекса. На многопроцессорных системах следует применять спин-блокировку.

В системе Windows 2000 Professional длительность кванта по умолчанию равна 20 мс; на однопроцессорных серверах его значение равно 120 мс; на многопроцессорных системах используются различные другие варианты в зависимости от частоты процессора. Более короткий квант улучшает работу интерактивных процессов, тогда как более длинный квант снижает количество переключений контекста и тем самым увеличивает производительность. Именно в этом смысл правой колонки табл. 3. Значения по умолчанию при желании могут быть увеличены в 2, 4 или 6 раз.

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