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

Ниже представлена не простая расшифровка доклада с семинара CLRium, а переработанная версия для книги .NET Platform Architecture. Той её части, что относится к потокам.

Потоки и планирование потоков

Что такое поток? Давайте дадим краткое определение. По своей сути поток это:

• Средство параллельного относительно других потоков исполнения кода;
• Имеющего общий доступ ко всем ресурсам процесса.

Очень часто часто слышишь такое мнение, что потоки в .NET — они какие-то абсолютно свои. И наши .NET потоки являются чем-то более облегчённым чем есть в Windows. Но на самом деле потоки в .NET являются самыми обычными потоками Windows (хоть Windows thread id и скрыто так, что сложно достать). И если Вас удивляет, почему я буду рассказывать не-.NET вещи в хабе .NET, скажу вам так: если нет понимания этого уровня, можно забыть о хорошем понимании того, как и почему именно так работает код. Почему мы должны ставить volatile, использовать Interlocked и SpinWait. Дальше обычного lock дело не уйдёт. И очень даже зря.

Давайте посмотрим из чего они состоят и как они рождаются. По сути поток — это средство эмуляции параллельного исполнения относительно других потоков. Почему эмуляция? Потому, что поток как бы странно и смело это ни звучало — это чисто программная вещь, которая идёт из операционной системы. А операционная система создаёт этот слой эмуляции для нас. Процессор при этом о потоках ничего не знает вообще.

Задача процессора — просто исполнять код. Поэтому с точки зрения процессора есть только один поток: последовательное исполнение команд. А задача операционной системы каким-либо образом менять поток т.о. чтобы эмулировать несколько потоков.

Поток в физическом понимании

«Но как же так?», — скажите вы, — «во многих магазинах и на различных сайтах я вижу запись «Intel Xeon 8 ядер 16 потоков». Говоря по-правде это — либо скудность в терминологии либо — чисто маркетинговый ход. На самом деле внутри одного большого процессора есть в данном случае 8 ядер и каждое ядро состоит из двух логических процессоров. Такое доступно при наличии в процессоре технологии Hyper-Threading, когда каждое ядро эмулирует поведение двух процессоров (но не потоков). Делается это для повышения производительности, да. Но по большому счёту если нет понимания, на каких потоках идут расчёты, можно получить очень не приятный сценарий, когда код выполняется со скоростью, ниже чем если бы расчёты шли на одном ядре. Именно поэтому раздача ядер идёт +=2 в случае Hyper-Threading. Т.е. пропуская парные ядра.

Технология эта — достаточно спорная: если вы работаете на двух таких псевдо-ядрах (логических процессорах, которые эмулируются технологией Hyper-Threading), которые при этом находятся на одном физическом ядре и работают с одной и той-же памятью, то вы будете постоянно попадать в ситуацию, когда второй логический процессор так же пытается обратиться к данной памяти, создавая блокировку либо попадая в блокировку, т.к. поток, находящийся на первом ядре работает с той же памятью.

Возникает блокировка совместного доступа: хоть и идёт эмуляция двух ядер, на самом-то деле оно одно. Поэтому в наихудшем сценарии эти потоки исполняются по очереди, а не параллельно.

Так если процессор ничего не знает о потоках, как же достигается параллельное исполнение потоков на каждом из его ядер? Как было сказано, поток — средство операционной системы выполнять на одном процессоре несколько задач одновременно. Достигается параллелизм очень быстрым переключением между потоками в течение очень короткого промежутка времени. Последовательно запуская на выполнение код каждого из потоков и делая это достаточно часто, операционная система достигает цели: делает их исполнение псевдопараллельным, но параллельным с точки зрения восприятия человека. Второе обоснование существования потоков — это утверждение, что программа не так часто срывается в математические расчёты. Чаще всего она взаимодействует с окружающим её миром: различным оборудованием. Это и работа с жёстким диском и вывод на экран и работа с клавиатурой и мышью. Поэтому чтобы процессор не простаивал, пока оборудование сделает то, чего хочет от него программа, поток можно на это время установить в состояние блокировки: ожидания сигнала от операционной системы, что оборудование сделало то, что от него просили. Простейший пример этого — вызов метода Console.ReadKey().

Если заглянуть в диспетчер задач Windows 10, то можно заметить, что в данный момент в вашей системе существует около 1,5 тысячи потоков. И если учесть, что квант на десктопе равен 20 мс, а ядер, например, 4, то можно сделать вывод, что каждый поток получает 20 мс работы 1 раз в 7,5 сек… Ну конечно же, нет. Просто почти все потоки чего-то ждут. То ввода пользователя, то изменения ключей реестра… В операционной системе существует очень много причин, чтобы что-либо ждать.

Так что пока одни потоки в блокировке, другие — что-то делают.

Создание потоков

Простейшая функция создания потоков в пользовательском режиме операционной системы — CreateThread. Эта функция создаёт поток в текущем процессе. Вариантов параметризации CreateThread очень много и когда мы вызываем new Thread(), то из нашего .NET кода вызывается данная функция операционной системы.

В эту функцию передаются следующие атрибуты:

1) Необязательная структура с атрибутами безопасности:

• Дескриптор безопасности (SECURITY_ATTRIBUTES) + признак наследуемости дескриптора.
  

  В .NET его нет, но можно создать поток через вызов функции операционной системы;

2) Необязательный размер стека:

• Начальный размер стека, в байтах (система округляет это значение до размера страницы памяти)
  

  Т.к. за нас размер стека передаёт .NET, нам это делать не нужно. Это необходимо для вызовов методов и поддержки памяти.

3) Указатель на функцию — точка входа нового потоками
4) Необязательный аргумент для передачи данных функции потока.

Из того, что мы не имеем в .NET явно — это структура безопасности с атрибутами безопасности и размер стэка. Размер стэка нас мало интересует, но атрибуты безопасности нас могут заинтересовать, т.к. сталкиваемся мы с ними впервые. Сейчас мы рассмотривать их не будем. Скажу только, что они влияют на возможность изменения информации о потоке средствами операционной системы.

Если мы создаём любым способом: из .NET или же вручную, средствами ОС, мы как итог имеем и ManageThreadId и экземпляр класса Thread.

Также у этой функции есть необязательный флаг: CREATE_SUSPENDED — поток после создания не стартует. Для .NET это поведение по умолчанию.

Помимо всего прочего существует дополнительный метод CreateRemoteThread, который создаёт поток в чужом процессе. Он часто используется для мониторинга состояния чужого процесса (например программа Snoop). Этот метод создаёт в другом процессе поток и там наш поток начинает исполнение. Приложения .NET так же могут заливать свои потоки в чужие процессы, однако тут могут возникнуть проблемы. Первая и самая главная — это отсутствие в целевом потоке .NET runtime. Это значит, что ни одного метод фреймворка там не будет: только WinAPI и то, что вы написали сами. Однако, если там .NET есть, то возникает вторая проблема (которой не было раньше). Это — версия runtime. Необходимо: понять, что там запущено (для этого необходимо импортировать не-.NET методы runtime, которые написаны на C/C++ и разобраться, с чем мы имеем дело). На основании полученной информации подгрузить необходимые версии наших .NET библиотек и каким-то образом передать им управление.

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

Планирование потоков

Для того чтобы понимать, в каком порядке исполнять код различных потоков, необходима организация планирования тих потоков. Ведь система может иметь как одно ядро, так и несколько. Как иметь эмуляцию двух ядер на одном так и не иметь такой эмуляции. На каждом из ядер: железных или же эмулированных необходимо исполнять как один поток, так и несколько. В конце концов система может работать в режиме виртуализации: в облаке, в виртуальной машине, песочнице в рамках другой операционной системы. Поэтому мы в обязательном порядке рассмотрим планирование потоков Windows. Это — настолько важная часть материала по многопоточке, что без его понимания многопоточка не встанет на своё место в нашей голове никоим образом.

Итак, начнём. Организация планирования в операционной системе Windows является: гибридной. С одной стороны моделируются условия вытесняющей многозадачности, когда операционная система сама решает, когда и на основе каких условия вытеснить потоки. С другой стороны — кооперативной многозадачности, когда потоки сами решают, когда они всё сделали и можно переключаться на следующий (UMS планировщик). Режим вытесняющей многозадачности является приоритетным, т.к. решает, что будет исполняться на основе приоритетов. Почему так? Потому что у каждого потока есть свой приоритет и операционная система планирует к исполнению более приоритетные потоки. А вытесняющей потому, что если возникает более приоритетный поток, он вытесняет тот, который сейчас исполнялся. Однако во многих случаях это бы означало, что часть потоков никогда не доберется до исполнения. Поэтому в операционной системе есть много механик, позволяющих потокам, которым необходимо время на исполнение его получить несмотря на свой более низкий по сравнению с остальными, приоритет.

Уровни приоритета

Картинка с сайта: habr.com

Windows имеет 32 уровня приоритета (0-31)

• 1 уровень (00 — 00) — это Zero Page Thread;
• 15 уровней (01 — 15) — обычные динамические приоритеты;
• 16 уровней (16 — 31) — реального времени.

Самый низкий приоритет имеет Zero Page Thread. Это — специальный поток операционной системы, который обнуляет страницы оперативной памяти, вычищая тем самым данные, которые там находились, но более не нужны, т.к. страница была освобождена. Необходимо это по одной простой причине: когда приложение освобождает память, оно может ненароком отдать кому-то чувствительные данные. Личные данные, пароли, что-то ещё. Поэтому как операционная система так и runtime языков программирования (а у нас — .NET CLR) обнуляют получаемые участки памяти. Если операционная система понимает, что заняться особо нечем: потоки либо стоят в блокировке в ожидании чего-либо либо нет потоков, которые исполняются, то она запускает самый низко приоритетный поток: поток обнуления памяти. Если она не доберется этим потоком до каких-либо участков, не страшно: их обнулят по требованию. Когда их запросят. Но если есть время, почему бы это не сделать заранее?

Продолжая говорить о том, что к нам не относится, стоит отметить приоритеты реального времени, которые когда-то давным-давно таковыми являлись, но быстро потеряли свой статус приоритетов реального времени и от этого статуса осталось лишь название. Другими словами, Real Time приоритеты на самом деле не являются таковыми. Они являются приоритетами с исключительно высоким значением приоритета. Т.е. если операционная система будет по какой-то причине повышать приоритет потока с приоритетом из динамической группы (об этом — позже, но, например, потому, что потоку освободили блокировку) и при этом значение до повышения было равно 15, то повысить приоритет операционная система не сможет: следующее значение равно 16, а оно — из диапазона реального времени. Туда повышать такими вот «твиками» нельзя.

Уровень приоритетов процессов с позиции Windows API.

Приоритеты — штука относительная. И чтобы нам всем было проще в них ориентироваться, были введены некие правила относительности расчетов: во-первых все потоки вообще (от всех приложений) равны для планировщика: планировщик не различает потоки это различных приложений или же одного и того же приложения. Далее, когда программист пишет свою программу, он задаёт приоритет для различных потоков, создавая тем самым модель многопоточности внутри своего приложения. Он прекрасно знает, почему там был выбран пониженный приоритет, а тут — обычный. Внутри приложения всё настроено. Далее, поскольку есть пользователь системы, он также может выстраивать приоритеты для приложений, которые запускаются на этой системе. Например, он может выбрать повышенный приоритет для какого-то расчетного сервиса, отдавая ему тем самым максимум ресурсов. Т.е. уровень приоритета можно задать и у процесса.

Однако, изменение уровня приоритета процесса не меняет относительных приоритетов внутри приложения: их значения сдвигаются, но не меняется внутренняя модель приоритетов: внутри по-прежнему будет поток с пониженным приоритетом и поток — с обычным. Так, как этого хотел разработчик приложения. Как же это работает?

Существует 6 классов приоритетов процессов. Класс приоритетов процессов — это то, относительно чего будут создаваться приоритеты потоков. Все эти классы приоритетов можно увидеть в «Диспетчере задач», при изменении приоритета какого-либо процесса.

Другими словами класс приоритета — это то, относительно чего будут задаваться приоритеты потоков внутри приложения. Чтобы задать точку отсчёта, было введено понятие базового приоритета. Базовый приоритет — это то значение, чем будет являться приоритет потока с типом приоритета Normal:

• Если процесс создаётся с классом Normal и внутри этого процесса создаётся поток с приоритетом Normal, то его реальный приоритет Normal будет равен 8 (строка №4 в таблице);
• Если Вы создаёте процесс и у него класс приоритета Above Normal, то базовый приоритет будет равен 10. Это значит, что потоки внутри этого процесса будут создаваться с более повышенным приоритетом: Normal будет равен 10.

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

Представим, что ваше приложение запускает пользователь и он решает, что ваше приложение потребляет слишком много процессорных ресурсов. Пользователь считает, что ваше приложение не столь важное в системе, как какие-нибудь другие приложения и понижает приоритет вашего приложения до Below Normal. Это означает, что он задаёт базовый приоритет 6 относительно которого будут рассчитываться приоритеты потоков внутри вашего приложения. Но в системе общий приоритет упадёт. Как при этом меняются приоритеты потоков внутри приложения?

Таблица 3

Normal остаётся на уровне +0 относительно уровня базового приоритета процесса. Below normal — это (-1) относительно уровня базового. Т.е. в нашем примере с понижением уровня приоритета процесса до класса Below Normal приоритет потока ‘Below Normal’ пересчитается и будет не 8 - 1 = 7 (каким он был при классе Normal), а 6 - 1 = 5. Lowest (-2) станет равным 4.

Idle и Time Critical — это уровни насыщения (-15 и +15). Почему Normal — это 0 и относительно него всего два шага: -2, -1, +1 и +2? Легко провести параллель с обучением. Мы ходим в школу, получаем оценки наших знаний (5,4,3,2,1) и нам понятно, что это за оценки: 5 — молодец, 4 — хорошо, 3 — вообще не постарался, 2 — это не делал ни чего, а 1 — это то, что можно исправить потом на 4. Но если у нас вводится 10-ти бальная система оценок (или что вообще ужас — 100-бальная), то возникает неясность: что такое 9 баллов или 7? Как понять, что вам поставили 3 или 4?

Тоже самое и с приоритетами. У нас есть Normal. Дальше, относительно Normal у нас есть чуть повыше
Normal (Normal above), чуть пониже Normal (Normal below). Также есть шаг на два вверх
или на два вниз (Higest и Lowest). Нам, поверьте, нет никакой необходимости в более подробной градации. Единственное, очень редко, может раз в жизни, нам понадобится сказать: выше чем любой приоритет в системе. Тогда мы выставляем уровень Time Critical. Либо наоборот: это надо делать, когда во всей системе делать нечего. Тогда мы выставляем уровень Idle. Это значения — так называемые уровни насыщения.

Как рассчитываются уровни приоритета?

Картинка с сайта: habr.com

У нас бал класс приоритета процесса Normal (Таблица 3) и приоритет потоков Normal — это 8. Если процесс Above Normal то поток Normal получается равен 9. Если же процесс выставлен в Higest, то поток Normal получается равен 10.

Поскольку для планировщика потоков Windows все потоки процессов равнозначны, то:

• Для процесса класса Normal и потока Above-Normal
• Для процесса класса Higest и потока Normal
  конечные приоритеты будут одинаковыми и равны 10.

Если мы имеем два процесса: один с приоритетом Normal, а второй — с приоритетом Higest, но при этом
первый имел поток Higest а второй Normal, то система их приоритеты будет рассматривать как одинаковые.

Как уже обсуждалось, группа приоритетов Real-Time на самом деле не является таковой, поскольку настоящий Real-Time — это гарантированная доставка сообщения за определённое время либо обработка его получения. Т.е., другими словами, если на конкретном ядре есть такой поток, других там быть не должно. Однако это ведь не так: система может решить, что низко приоритетный поток давно не работал и дать ему время, отключив real-time. Вернее его назвать классом приоритетов который работает над обычными приоритетами и куда обычные приоритеты не могут уйти, попав под ситуации, когда Windows временно повышает им приоритет.

Но так как поток повышенным приоритетом исполняется только один на группе ядер, то получается,
что если у вас даже Real-Time потоки, не факт, что им будет выделено время.

Если перевести в графический вид, то можно заметить, что классы приоритетов пересекаются. Например, существует пересечение Above-Normal Normal Below-Normal (столбик с квадратиками):

Картинка с сайта: habr.com

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

Поэтому, когда процессу выдаётся более высокий класс приоритета, это повышает приоритет потоков процесса относительно обычных – с классом Normal.

Кстати говоря, мы стартовали продажи на CLRium #7, в котором мы с огромным удовольствием будем говорить про практику работы с многопоточным кодом. Будут и домашние задания и даже возможность работы с личным ментором.

Загляните к нам на сайт: мы сильно постарались, чтобы его было интересно изучить.

Введение

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

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

Процедура планирования обычно связана с весьма затратной процедурой диспетчеризации — переключением процессора на новый поток, поэтому планировщик должен заботиться об эффективном использовании процессора. Принадлежность потоков к процессу при планировании не учитывается, то есть единицей планирования в ОС Windows является именно поток. Запуск процедуры планирования удобно проиллюстрировать на упрощенной (по сравнению с диаграммой, изображенной на
рис.
5.3) диаграмме состояний потока, см.
рис.
6.1.

Картинка с сайта: intuit.ru

Рис.
6.1.
Упрощенная диаграмма состояний потоков в ОС Windows

Наиболее важным вопросом планирования является выбор момента для принятия решения. В ОС Windows запуск процедуры планирования вызывается одним из следующих событий.

Это, во-первых, события, связанные с освобождением процессора.

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

(2) Переход потока в состояние готовности в связи с тем, что его квант времени истек

(3) Переход потока в состояние ожидания

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

(4) Поток вышел из состояния ожидания

(5) Поток только что создан

(6) Деятельность текущего потока может иметь следствием вывод другого потока из состояния ожидания.

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

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

Заметим, что переключение из пользовательского режима в режим ядра (и обратно) не влияет на планирование потока, так как контекст в этом случае не меняется.

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

Перевод потока из состояния ожидания в состояние готовности (вариант 4) может быть следствием прерывания, свидетельствующим об окончании операции ввода-вывода. В этом случае процедура планирования может быть отложена (deffered procedure call) до окончания выполнения высокоприоритетного системного кода.

Иногда подобный переход происходит в результате деятельности другого потока, который, например, выполнил операцию up на семафоре (пример 6-го варианта). Хотя этот другой поток и может продолжить работу, он должен запустить процедуру планирования, поскольку в очереди готовности могут оказаться потоки с более высоким приоритетом. По тем же причинам планирование осуществляется в случае запуска нового потока.

Алгоритмы планирования

Приоритеты

В ОС Windows реализовано вытесняющее приоритетное планирование, когда каждому потоку присваивается определенное числовое значение — приоритет, в соответствии с которым ему выделяется процессор. Потоки с одинаковыми приоритетами планируются согласно алгоритму Round Robin (карусель). Важным достоинством системы является возможность вытеснения потоков, работающих в режиме ядра — код исполнительной системы полностью реентерабелен. Не вытесняются лишь потоки, удерживающие спин-блокировку (см.
«Синхронизация потоков»
). Поэтому спин-блокировки используются с большой осторожностью и устанавливаются на минимальное время.

В системе предусмотрено 32 уровня приоритетов. Шестнадцать значений приоритетов (16-31) соответствуют группе приоритетов реального времени, пятнадцать значений (1-15) предназначены для обычных потоков, и значение 0 зарезервировано для системного потока обнуления страниц (см.
рис.
6.2).

Картинка с сайта: intuit.ru

Рис.
6.2.
Приоритеты потоков

Чтобы избавить пользователя от необходимости запоминать числовые значения приоритетов и иметь возможность модифицировать планировщик, разработчики ввели в систему слой абстрагирования приоритетов. Например, класс приоритета для всех потоков конкретного процесса можно задать с помощью набора констант-параметров функции SetPriorityClass, которые могут иметь следующие значения:

• реального времени ( REALTIME_PRIORITY_CLASS ),
• высокий ( HIGH_PRIORITY_CLASS ),
• выше нормы ( ABOVE_NORMAL_PRIORITY_CLASS ),
• нормальный ( NORMAL_PRIORITY_CLASS ),
• ниже нормы ( BELOW_NORMAL_PRIORITY_CLASS )
• и неработающий ( IDLE_PRIORITY_CLASS ).

Относительный приоритет потока устанавливается аналогичными параметрами функции SetThreadPriority:

Совокупность из шести классов приоритетов процессов и семи классов приоритетов потоков образует 42 возможные комбинации и позволяет сформировать так называемый базовый приоритет потока (см. таб. 6.1).

Базовый приоритет процесса и первичного потока по умолчанию равен значению из середины диапазонов приоритетов процессов (24, 13, 10, 8, 6 или 4). Смена приоритета процесса влечет за собой смену приоритетов всех его потоков, при этом их относительные приоритеты остаются без изменений.

Приоритеты с 16 по 31 в действительности приоритетами реального времени не являются, поскольку в рамках поддержки мягкого реального времени, которая реализована в ОС Windows, никаких гарантий относительно сроков выполнения потоков не дается. Это просто более высокие приоритеты, которые зарезервированы для системных потоков и тех потоков, которым такой приоритет дает пользователь с административными правами. Тем не менее, наличие приоритетов реального времени, а также вытесняемость кода ядра, локализация страниц памяти (см.
«Функционирование менеджера памяти»
) и ряд дополнительных возможностей — все это позволяет выполнять в среде ОС Windows приложения мягкого реального времени, например, мультимедийные. Системный поток с нулевым приоритетом занимается обнулением страниц памяти. Обычные пользовательские потоки могут иметь приоритеты от 1 до 15.

Давайте поговорим о приоритетах Windows процессов. В большинстве случаев «играться» с настройкой приоритетов нет необходимости, но, иногда, грамотный системный администратор может помочь системе более правильно распределить процессорное время между запущенными задачами. Единого рецепта нет, но путем «подбора и перебора» это вполне реализуемо. Где это может понадобиться? Например, в связке 1С-SQL можно дать больше процессорного времени 1С и SQL, как наиболее критичным к ресурсам процессам.

В общем случае, посмотреть и изменить приоритет запущенного процесса можно через Task Manager

Windows NT/2000/7/2008

Картинка с сайта: winitpro.ru

В Windows 2012 это “закопали» чуть глубже

Картинка с сайта: winitpro.ru

Как видно из приведенных примеров, вам доступно всего 6 приоритетов (как выяснится позже, это классы приоритетов). Достаточно? Microsoft считает, что да. Но давайте вспомним «легендарную» фразу Билла Гейста, который сказал, что «640 KB of RAM will be enough for everybody”. Но время показало, что это далеко не так. : )

А теперь давайте разберемся, как это есть на самом деле.

На самом деле в Windows существует 32 уровня приоритета, от 0 до 31.

Они группируются так:

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

При создании процесса, ему назначается один из шести классов приоритетов:

1. Real time class (значение 24),
2. High class (значение 13),
3. Above normal class (значение 10),
4. Normal class (значение 8),
5. Below normal class (значение 6),
6. или Idle class (значение 4).

Посмотреть приоритет процесса, как писалось выше, можно, используя Task Manager.

Примечание: Приоритеты Above normal и Below normal появились, начиная с Windows 2000.

Приоритет каждого потока (базовый приоритет потока) складывается из приоритета его процесса и относительного приоритета самого потока. Есть семь относительных приоритетов потоков:

1. Normal: такой же как и у процесса;
2. Above normal: +1 к приоритету процесса;
3. Below normal: -1;
4. Highest: +2;
5. Lowest: -2;
6. Time critical: устанавливает базовый приоритет потока для Real time класса в 31, для остальных классов в 15.
7. Idle: устанавливает базовый приоритет потока для Real time класса в 16, для остальных классов в 1.

В следующей таблице показаны приоритеты процесса, относительный и базовый приоритеты потока.

Теперь, когда мы все это узнали, что же с этим всем можно сделать? Ну, например, начать использовать.

Как еще можно запустить процесс с «нестандартным» приоритетом или изменить?

Метод 1. Запустить задачу/процесс и изменить приоритет через Task Manager.

Минусы метода:

• Доступно только 6 приоритетов
• Переключение приоритетов производится мышкой, не автоматизируется.

Метод 2. Можно воспользоваться командой START с соответствующими ключами

Доступные ключи, отвечающие за приоритеты, следующие (я умышленно опускаю ключи командной строки команды START не имеющие отношения к описываемому процессу работы с приоритетами):

C:\>start /?
Starts a separate window to run a specified program or command.
START ["title"] [/D path] [/I] [/MIN] [/MAX] [/SEPARATE | /SHARED]
[/LOW | /NORMAL | /HIGH | /REALTIME | /ABOVENORMAL | /BELOWNORMAL]
[/NODE <NUMA node>] [/AFFINITY <hex affinity mask>] [/WAIT] [/B]
[command/program] [parameters]
LOW       Start application in the IDLE priority class.
NORMAL     Start application in the NORMAL priority class.
HIGH       Start application in the HIGH priority class.
REALTIME   Start application in the REALTIME priority class.
ABOVENORMAL Start application in the ABOVENORMAL priority class.
BELOWNORMAL Start application in the BELOWNORMAL priority class.

Как видим, команда START дает возможность запустить процесс все с теми же 6-ю приоритетами, которые доступны через Task Manager

Минус метода:

• Доступно только 6 приоритетов

Метод 3. Использование утилиты wmic.exe

Как было показано выше, Task Manager, и команда START достаточно неуклюжи для задачи назначения приоритетов. Посмотрим, как это применять более гибко. Будем использовать утилиту wmic.exe.

Командная строка:

wmic process where name="AppName" CALL setpriority ProcessIDLevel

Пример:

wmic process where name="calc.exe" CALL setpriority 32768

или

wmic process where name="calc.exe" CALL setpriority "above normal"

Приоритеты (предопределенные):

• idle: 64
• below normal: 16384
• normal: 32
• above normal: 32768
• high priority: 128
• real time: 256

Отступление. Что делать если существует несколько одноименных процессов? Приоритет процесса можно менять как по имени процесса, так и с использованием PID (Process ID) процесса.

Вот короткий пример запуска wmic.exe для получения необходимой информации

Используем команду:

wmic process list brief

Примечание: пример выполнения этой команды приводить не буду. Слишком большой список процессов получается. Сделаете это самостоятельно, при желании.

Вы получите список процессов, запущенных на вашем локальном компьютере. Теперь выполните команду:

wmic process list brief | find "cmd.exe"

Результат:

Картинка с сайта: winitpro.ru

Специально запустил несколько копий cmd.exe, чтобы иллюстрация была более полной.

Теперь список процессов ограничен только теми процессами, в имени исполняемого модуля которых присутствует строка «cmd.exe». Обратите внимание на PID процесса(ов).

Теперь давайте попробуем отобрать интересующие нас процессы, используя непосредственно WMI и не прибегая к стандартным средствам командной строки. Для этого просто напишите:

wmic process where description='cmd.exe' list brief

Результат:

Картинка с сайта: winitpro.ru

Сравните полученные результаты. Запомните PID процесса CMD.EXE.

Командная строка для запуска wmic.exe

wmic process where processid='XXXX' CALL setpriority ProcessIDLevel

Ну а теперь можем изменить приоритет конкретного процесса (например с PID=8476):

wmic process where processid='8476' CALL setpriority 32768

или

wmic process where processid='8476' CALL setpriority "above normal"

А что дальше? Прикидывать, пробовать, подбирать и тонко регулировать приоритеты. Улучшая работу сервисов и процессов, а также работу конечных пользователей.

Понятие приоритета
потока.

Поток получает
доступ к процессору на 20 мс, после чего
планировщик переключает процессор на
выполнение другого потока. Так происходит,
только если у всех потоков один приоритет,
но на самом деле в системе существуют
потоки с разными приоритетами, а это
меняет порядок распределения процессорного
времени.

Каждому потоку
присваивается уровень приоритета – от
0 (самый низкий) до 31 (самый высокий).
Решая, какому потоку выделить процессорное
время, система сначала рассматривает
только потоки с приоритетом 31 и подключает
их к процессору по принципу карусели.
Пока в системе имеются планируемые
потоки с приоритетом 31, ни один поток с
более низким приоритетом процессорного
времени не получает. Такая ситуация
называется «голоданием* (starvation). Она
наблюдается, когда потоки с более высоким
приоритетом так интенсивно используют
процессорное время, что остальные
практически не работают. Вероятность
этой ситуации намного ниже в
многопроцессорных системах, где потоки
с приоритетами 31 и 30 могут выполняться
одновременно. Система всегда старается,
чтобы процессоры были загружены работой,
и они простаивают только в отсутствие
планируемых потоков.

Потоки с более
высоким приоритетом всегда вытесняют
потоки с более низким приоритетом
независимо от того, исполняются последние
или нет. Допустим, процессор исполняет
поток с приоритетом 5, и тут система
обнаруживает, что поток с более высоким
приоритетом готов к выполнению. Система
остановит поток с более низким приоритетом
– даже если не истек отведенный ему
квант процессорного времени – и подключит
к процессору поток с более высоким
приоритетом.

При загрузке
системы создается особый поток – поток
обнуления страниц (zero page thread), которому
присваивается нулевой уровень приоритета.
Ни один поток, кроме этого, не может
иметь нулевой уровень приоритета. Он
обнуляет свободные страницы в оперативной
памяти при отсутствии других потоков,
требующих внимания со стороны системы.

Классы приоритета
процессов.

Windows поддерживает
шесть классов приоритета:

• idle(простаивающий),

• belownormal (ниже
  обычного),

• normal(обычный),

• abovenormal (выше
  обычного),

• high(высокий),

• realtime(реального
  времени).

Самый распространенный
класс приоритета – normal, его использует
99% приложений.

Real-lime.Потоки
в этом процессе обязаны немедленно
реагировать на события, обеспечивая
выполнение критических по времени
задач. Такие потоки вытесняют даже
компоненты операционной системы.

High.Потоки в
этом процессе тоже должны немедленно
реагировать на события, обеспечивая
выполнение критических по времени
задач.

Above normal. Класс
приоритета, промежуточный между normal и
high. Это новый класс, введенный в Windows
2000.

Normal.Потоки в
этом процессе не предъявляют особых
требований к выделению им процессорного
времени.

Below normal.Класс
приоритета, промежуточный между normal и
idle. Это новый класс, введенный в Windows
2000.

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

Относительный
приоритет потока.

Могут быть следующие
относительные приоритеты потока.

Time-critical.Поток
выполняется с приоритетом 31 в классе
real-time и с приоритетом 15 в других классах.

Highest.Поток
выполняется с приоритетом на два уровня
выше обычною для данного класса.

Above normal.Поток
выполняется с приоритетом на один
уровень выше обычного для данного
класса.

Normal.Поток
выполняется с обычным приоритетом
процесса для данного класса.

Below normal.Поток
выполняется с приоритетом на один
уровень ниже обычного для данного
класса.

Lowest.Поток
выполняется с приоритетом на два уровня
ниже обычного для данного класса

Idle.Поток
выполняется с приоритетом 16 в классе
real-time и с приоритетом 1 в других классах

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

В системе
предусмотрена возможность изменения
класса приоритета самим выполняемым
процессом – вызовом функции
SetPriorityClass:

BOOL
SetPriontyClass(
HANDLE hProcess,
DWORD fdwPriority);

Эта функция меняет
класс приоритета процесса, определяемого
описателем hProcess, в соответствии со
значением параметраfdwPriority.

Динамическое
изменение уровня приоритета потока.

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

Система повышает
приоритет только тех потоков, базовый
уровень которых находится в пределах
1-15 Именно поэтому данный диапазон
называется «областью динамического
приоритета» (dynamic priority range). Система не
допускает динамического повышения
приоритета потока до уровней реального
времени (более 15) Поскольку потоки с
такими уровнями обслуживают системные
функции, это ограничение не дает
приложению нарушить работу операционной
системы.

Для отключения
механизма динамического изменения
приоритета есть две функции:

BOOL
SetProcessPriorityBoost(
HANDLE hProcess,
BOOL DisablePriontyBoost);

BOOL
SetThreadPriorityBoost(
HANDLE hThread,
BOOL DisablePriorityBoost);

SetProcessPriorityBoostзаставляет систему включить или отключить
изменение приоритетов всех потоков в
указанном процессе, aSetThreadPriorityBoostдействует применительно к отдельным
потокам. Эти функции имеют свои аналоги,
позволяющие определять, разрешено или
запрещено изменение приоритетов:

BOOL
GetProcessPriorityBoost(
HANDLE hProcess,

PBOOL
pDisablePriorityBoost);

BOOL
GeLThreadPriorityBoost(
HANDLE hThread,

PBOOL
pDisablePriorityBoost);

Каждой из этих
двух функций передаётся описатель
нужного процесса или потока и адрес
переменной чипа BOOL, в которой и возвращается
результат.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #

  11.05.201529.07 Mб68Matlab.djvu

• #
• #
• #
• #