Приоритет голодающего потока в ос windows повышается на время

• 

• Базовый
  и динамический приоритеты потока:

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

• — Использование
  динамических
  приоритетов,
  изменяющихся во времени, позволяет
  реализовать адаптивное планирование,
  при котором не дискриминируются
  интерактивные задачи, часто выполняющие
  операции ввода-вывода и недоиспользующие
  выделенные им кванты.

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

• Динамические
  приоритеты:

• 

• В
  ходе выполнения нити ее приоритет
  (1-15) может меняться – механизм адаптивного
  планирования.

• 16. Граф состояний потоков в ms Windows 2000-2003. Поток простоя. Принципы адаптивного планирования.

• 16.1 Граф состояний потоков в ms Windows 2000.

• 

• Готовность.
  При поиске потока на выполнение
  диспетчер просматривает только потоки,
  находящиеся в состоянии готовности,
  у которых есть все для выполнения, но
  не хватает только процессора.

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

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

• Ожидание.
  Поток может входить в состояние ожидания
  несколькими способами: поток по своей
  инициативе ожидает некоторый объект
  для того, чтобы синхронизировать свое
  выполнение, например, ожидает завершение
  операции ввода-вывода.

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

• Завершение.
  Когда выполнение потока закончилось,
  он входит в состояние завершения.

• Условия
  освобождения потоком процессора:

• — исчерпан
  квант;

• — появляется
  более приоритетный готовый поток;

• — поток
  сам добровольно переходит в очередь
  готовых (Sleep
  (0), SwitchToThread);

• — поток
  добровольно блокируется, уходя в
  состояние ожидания (Sleep
  (n),
  WaitForSingleObject,
  синхронный ввод/вывод, …);

• — поток
  снижает свой приоритет;

• — поток
  добровольно исключает текущий процессор
  из маски совместимости (привязки) (для
  МПС);

• — поток
  завершает свое выполнение.

• Граф
  состояний потоков для Windows
  2003:

• 

• Обратите внимание
  на новое состояние Deferred
  Ready
  (готов, отложен). Это состояние
  используется для потоков, выбранных
  для выполнения на конкретном процессоре,
  но пока не запланированных к выполнению.

• Это
  новое состояние предназначено для
  того, чтобы ядро могло свести к минимуму
  срок применения общесистемной блокировки
  к базе данных планирования (scheduling
  database).

• 16.2 Поток простоя.

• Если
  нет ни одного потока, готового к
  выполнению на процессоре. Windows
  подключает к данному процессору поток
  простоя.

• Поток
  простоя не имеет приоритета, поскольку
  он выполняется лишь в отсутствие других
  потоков.

• Для
  каждого процессора (в МПС) создается
  свой поток простоя.

• Поток
  простоя выполняет следующие действия:

• 1.
  Включает и отключает прерывания (тем
  самым давая возможность доставить
  отложенные

• прерывания).

• 2.
  Проверяет, нет ли у процессора
  незавершенных отложенных программных
  прерываний (DPC
  –

• Deferred
  procedure call). Если таковые есть, сбрасывает
  отложенное программное прерывание и

• доставляет
  эти DPC.

• 3.
  Проверяет, выбран ли какой-нибудь поток
  для выполнения на данном процессоре,
  и, если да,

• организует его
  диспетчеризацию.

• 4.
  Вызывает из HAL
  процедуру обработки процессора в
  простое (если нужно выполнить какие-либо

• функции
  управления электропитанием).

• 5.
  В Windows
  Server
  2003 поток простоя также проверяет
  наличие потоков, ожидающих выполнения

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

• многопроцессорных
  системах.

• 16.3 Принципы адаптивного планирования.

• Если
  поток полностью исчерпал свой квант,
  то его приоритет понижается на некоторую
  величину.

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

• Приоритет не
  изменяется, если поток вытеснен более
  приоритетным потоком.

• Повышение приоритета
  для “голодающих” потоков.

• Пример
  “голодающего” потока:

• Представьте, что
  поток с приоритетом 4 готов к выполнению,
  но не может получить доступ к процессору
  из-за того, что его постоянно занимают
  потоки с приоритетом 8.

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

• 17. Граф состояний потоков в ms Windows 2000-2003. Особенности планирования в многопроцессорных системах.

• 17.2 Особенности планирования в многопроцессорных системах.

• Управление
  потоками в МПС:

• Операционные
  системы Windows
  2000-2003 руководствуется следующими
  базовыми стратегиями для решения того,
  на каких процессорах какие потоки
  выполняются:

• — выбор
  процессора для готового потока, при
  наличии простаивающих процессоров;

• — выбор
  процессора для готового потока, при
  отсутствии простаивающих процессоров;

• — выбор
  потока для конкретного процессора,
  который освободился.

• Выбор
  процессора для потока при наличии
  простаивающих:

• Как
  только поток готов к выполнению, Windows
  сначала пытается подключить его к
  простаивающему процессору.

• Если
  таких процессоров несколько, то выбор
  процессора производится в зависимости
  от версии операционной системы Windows
  (см. далее).

• Как
  только процессор выбран, соответствующий
  поток переводится в состояние Standby.

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

• Выбор
  процессора для потока:

• Выбор
  процессора для потока в Windows
  2000:

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

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

• Выбор
  процессора для потока в Windows
  XP
  и 2003:

• Выделяются
  простаивающие процессоры из числа
  тех, на которых маска привязки разрешает
  выполнение данного потока. Если маска
  привязки разрешает выполнение потока
  на текущем процессоре, то поток
  планируется к выполнению именно на
  этом процессоре.

• Если
  маска привязки не разрешает выполнение
  потока на текущем процессоре, то
  выполняется следующий алгоритм.

• Алгоритм выбор
  процессора для потока в Windows
  XP
  и 2003:

• Если
  система имеет архитектуру NUMA
  и в узле, где находится идеальный
  процессор для потока, есть простаивающие
  процессоры, то список всех простаивающих
  процессоров уменьшается до этого
  набора. Если в результате такой операции
  в списке не останется простаивающих
  процессоров, список не сокращается.

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

• Если
  текущий процессор относится к набору
  оставшихся простаивающих процессоров,
  поток планируется к выполнению именно
  на этом процессоре.

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

• Из
  оставшегося набора простаивающих
  процессоров исключаются все процессоры,
  находящиеся в состоянии сна. (Эта
  операция не выполняется. если в ее
  результате такой список опустел бы.)

• Поток
  подключается к процессору с наименьшим
  номером в оставшемся списке.

• Выбор
  процессора для потока при отсутствии
  простаивающих:

• При
  отсутствии простаивающего процессора
  Windows
  выполняет постановку нового потока
  на идеальный процессор:

• 1.
  Если этот процессор не входит в маску
  привязки потока, Windows
  выбирает для потока процессор с
  наибольшим номером (в Windows
  2000 маска привязки может исключить
  идеальный процессор).

• 2.
  Если к идеальному процессору уже
  подключен какой-то поток, Windows
  сравнивает приоритеты текущего и
  нового потока. Если приоритет выполняемого
  потока меньше, чем нового, то текущий
  поток вытесняется в пользу нового.

• 3.
  Если для идеального процессора уже
  выбран поток, ожидающий в состоянии
  Standby
  выделения процессорного времени, и
  его приоритет ниже, чем потока,
  готовящегося к выполнению, последний
  вытесняет первый и становится следующим
  выполняемым на данном процессоре.

• Выбор
  потока для конкретного процессора
  (Windows
  2000 и XP):

• В
  многопроцессорной системе Windows
  2000 или Windows
  ХР из очереди готовых выбирается поток
  с наивысшим приоритетом, для которого
  выполняется одно из дополнительных
  условий:

• — поток
  уже выполнялся в прошлый раз на данном
  процессоре;

• — данный
  процессор должен быть идеальным для
  этого потока;

• — поток
  провел в состоянии Ready
  более трех тактов системного таймера;

• — поток
  имеет приоритет не менее 24.

• Выбор
  потока для конкретного процессора
  (Windows
  2003):

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

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

• Заметьте,
  что в NUMA-системах
  поток простоя проверяет процессоры
  сначала в своем узле, а потом в других
  узлах.

• 18. Граф состояний потоков в ms Windows 2000-2003. Особенности планирования в ос ms Windows Vista и Server 2008.

• 18.2 Особенности планирования в ос ms Windows Vista и Server 2008.

• Проблема
  неравномерного распределения ресурсов
  процессора:

• Все
  версии ОС Windows собирают статистику
  загрузки процессора, для этого каждые
  10 или 15 мс (в зависимости от аппаратной
  платформы), выполняетcя
  подпрограмма прерывания интервального
  таймера.

• Данная
  подпрограмма обновляет статистику
  загрузки процессора потоком, который
  был ею прерван. При этом в версиях ОС
  Windows младше Vista
  и Server
  2008 считается, что этот поток выполнялся
  весь интервал, хотя в действительности
  выполнение потока могло начаться перед
  самым завершением данного интервала.

• Далее
  возможна ситуация, когда поток может
  формально получить ресурсы процессора,
  но не получить возможности выполняться,
  поскольку вместо этого могли быть
  выполнены подпрограммы аппаратного
  или программного прерывания.

• Таким
  образом, использование подобного
  механизма сбора статистики загрузки
  процессора может приводить к
  нерациональному распределению ресурсов
  самого процессора.

• Рассмотрим
  случай, если два потока с одинаковым
  приоритетом одновременно готовы к
  выполнению:

• Поток
  A выполняется до завершения следующего
  временного интервала, когда планировщик
  предполагает, что он выполнялся в
  течение всего интервала, и поэтому
  решает, что очередь потока A закончилась.
  Более того, потоку A засчитывается еще
  и прерывание, произошедшее во время
  его выполнения.

• На
  следующий интервал планировщик отдает
  предпочтение потоку B, который выполняется
  в течение полного интервала.

• 

• Усовершенствования
  ядра ОС Windows Vista – Server
  2008:

• В
  ОС Windows Vista и Server
  2008 для более равномерного выделения
  ресурсов вводится использование
  счетчика циклов процессора.

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

• Это
  означает, что поток в ОС Windows Vista и Server
  2008 всегда получит, по крайней мере,
  свою очередь выполнения, не превышающую
  один дополнительный временной интервал,
  что обеспечивает более справедливое
  выделение ресурсов и предсказуемое
  поведение приложений.

• Решение
  неравномерного распределения ресурсов
  ЦП:

• На
  рисунке показан пример решения описанной
  ситуации неравномерного распределения
  ресурсов ЦП — ядро Windows
  Vista
  выделяет обоим потокам как минимум,
  по одному временному интервалу
  выполнения.

• 

• 19. Планирование загрузки процессорного времени в ms windows 2000-2003. Функции win 32 api создания и завершение процессов и потоков, управление потоками

• Планирование
  загрузки процессорного времени:

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

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

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

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

• API
  Win32
  для управления потоками:

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

• HANDLE
  CreateThread
  (

• PSECURITY_ATTRIBUTES
  psa,

• SIZE_T
  cbStack,
  PTHREAD_START_ROUTINE pfnStartAddr,

• PVOID
  pvParam,

• DWORD
  dwCreate,

• PDWORD
  pdwThreadID

• );

• Параметры
  создания потока

• Параметр psa
  является
  указателем на структуру SECURITY_ATTRIBUTES.

• Если Вы хотите,
  чтобы объекту ядра «поток» были
  присвоены атрибуты защиты по умолчанию
  (что чаще всего и бывает), передайте в
  этом параметре NULL A чтобы дочерние
  процессы смогли наследовать описатель
  этого объекта, определите структуру
  SECURI TY_ATTRIBUTES и инициализируйте ее элемент
  hlnheritHandle
  значением
  TRUE.

• Параметр cbStack
  определяет,
  какую часть адресного пространства
  поток сможет использовать под свой
  стек. Каждому потоку выделяется
  отдельный стек.

• Параметр
  pfnStartAddr
  определяет
  адрес функции потока, с которой должен
  будет начать работу создаваемый поток,
  а параметр
  pvParam
  идентичен
  параметру
  рvРаrаm
  функции
  потока. CreateTbread
  лишь
  передает
  этот параметр по эстафете той функции,
  с которой начинается выполнение
  создаваемого потока. Таким образом,
  данный параметр позволяет передавать
  функции потока какое-либо инициализирующее
  значение. Оно может быть или просто
  числовым значением, или указателем на
  структуру данных с дополнительной
  информацией.
  Вполне
  допустимо и даже полезно создавать
  несколько потоков, у которых в качестве
  входной точки используется адрес одной
  и той же функции. Например, можно
  реализовать Web-сервер, который
  обрабатывает каждый клиентский запрос
  в от дельном потоке. При создании
  каждому потоку передается свое значение
  рvParam.

• Параметр
  fdwCreate определяет
  дополнительные флаги, управляющие
  созданием потока. Он принимает одно
  из двух значений. 0 (исполнение потока
  начинается немедленно) или CREATE_SUSPENDED.
  В последнем случае система создает
  поток, инициализирует его и приостанавливает
  до последующих указаний. Флаг
  CREATE_SUSPENDED позволяет программе изменить
  какие-либо свойства потока перед тем,
  как он начнет выполнять код.

• Параметр
  pdwThreadlD—
  это адрес
  переменной типа DWORD, в которой функция
  возвращает идентификатор, приписанный
  системой новому потоку. В Windows 2000 и
  Windows NT 4 в этом параметре можно передавать
  NULL (обычно так и делается). Тем самым
  Вы сообщаете функции, что Вас не
  интересует идентификатор потока в
  Windows 95/98 это приведет к ошибке, так как
  функция попытается записать идентификатор
  потока по нулевому адресу, что
  недопустимо. И поток не будет создан.

• Функция
  CreateRemoteThread

• Функция
  CreateRemoteThread
  создает поток, который запускается в
  виртуальном адресном пространстве
  другого процесса.

• HANDLE
  CreateRemoteThread(

• HANDLE
  hProcess,     //
  дескриптор
  процесса

• LPSECURITY_ATTRIBUTES
  lpThreadAttributes,
  // дескриптор
  защиты
  (SD)

• SIZE_T
  dwStackSize, //
  размер начального стека

• LPTHREAD_START_ROUTINE
  lpStartAddress,   // функция
  потока

• LPVOID
  lpParameter,  // аргументы
  потока

• DWORD
  dwCreationFlags, // параметры
  создания

• LPDWORD
  lpThreadId 
  // идентификатор потока

• ); 

• Установка
  приоритета:

• Поток создается с
  приоритетом потока THREAD_PRIORITY_NORMAL.
  Используйте функции GetThreadPriority
  и SetThreadPriority,
  чтобы получать и установить приоритетное
  значение потока.

• BOOL
  SetThreadPriority(

• HANDLE
  hThread,
  // дескриптор
  потока

• int
  nPriority  
  // уровень приоритета потока

• );

• Функция
  SetThreadPriority
  дает возможность установки базового
  уровня приоритета потока относительно
  класса приоритета его процесса.
  Например, устанавливая THREAD_PRIORITY_HIGHEST
  при вызове SetThreadPriority
  для потока процесса IDLE_PRIORITY_CLASS
  базовый уровень приоритета потока
  устанавливается в значение 6.

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

  Приоритет	Назначение
  THREAD_PRIORITY_ABOVE_NORMAL	Приоритет на 1 пункт выше класса приоритета.
  THREAD_PRIORITY_BELOW_NORMAL	Приоритет на 1 пункт ниже класса приоритета.
  THREAD_PRIORITY_HIGHEST	Приоритет на 2 пункта выше класса приоритета.
  THREAD_PRIORITY_IDLE	Базовый приоритет 1 для процессов IDLE_PRIORITY_CLASS, BELOW_NORMAL_PRIORITY_CLASS, NORMAL_PRIORITY_CLASS, ABOVE_NORMAL_PRIORITY_CLASS или HIGH_PRIORITY_CLASS и уровень базового приоритета 16 для процессов REALTIME_PRIORITY_CLASS.
  THREAD_PRIORITY_LOWEST	Приоритет на 2 пункта ниже класса приоритета.
  THREAD_PRIORITY_NORMAL	Нормальный приоритет класса приоритета.
  THREAD_PRIORITY_TIME_CRITICAL	Базовый приоритет 15 для процессов IDLE_PRIORITY_CLASS, BELOW_NORMAL_PRIORITY_CLASS, NORMAL_PRIORITY_CLASS, ABOVE_NORMAL_PRIORITY_CLASS или HIGH_PRIORITY_CLASS и уровень базового приоритета 31 для процессов REALTIME_PRIORITY_CLASS.

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

• Поток можно завершить
  четырьмя способами:

• 1.
  функция потока возвращает управление
  (рекомендуемый способ);

• 2.
  поток самоуничтожается вызовом функции
  ExitThread
  (нежелательный
  способ);

• 3.
  один из потоков данного или стороннего
  процесса вызывает функцию TerminateThread
  (нежелательный
  способ);

• 4.
  завершается процесс, содержащий данный
  поток (тоже нежелательно).

• Явный вызов
  ExitThread и
  TerminateThread нежелателен,
  т.к. процесс
  продолжает работать, но при этом весьма
  вероятна утечка памяти или других
  ресурсов.

• Возврат
  управления функцией потока
  

• При
  этом:

• —
  любые С++-объекты, созданные данным
  потоком, уничтожаются соответствующими
  деструкторами;

• —
  система корректно освобождает память,
  которую занимал стек потока;

• —
  система устанавливает код завершения
  данного потока (поддерживаемый объектом
  ядра «поток”) –его и возвращает
  Ваша функция потока;

• —
  счетчик пользователей данного объекта
  ядра «поток» уменьшается на 1.

• Функция
  ExitThread
  

• Поток
  можно завершить принудительно, вызвав:

• VOID
  ExitThread(DWORD
  dwExitCоde);

• В
  параметр dwExitCode
  Вы помещаете
  значение, которое система рассматривает
  как код завершения потока.

• Функция
  TerminateThread
  

• Вызов
  этой функции также завершает поток:

• BOOL
  TerminateThread(
  HANDLE hThread, DWORD dwExitCode);

• В
  параметр dwExitCode
  помещается
  код завершения потока. После того как
  поток будет уничтожен, счетчик
  пользователей его объекта ядра «поток”
  уменьшится.

• Если
  завершается процесс:

• Функции ExitProcess
  и TerminateProcess
  принудительно завершают потоки,
  принадлежащие завершаемому процессу.

• Эти функции
  прекращают выполнение всех потоков,
  принадлежавших завершенному процессу.
  При этом гарантируется высвобождение
  любых выделенных процессу ресурсов,
  в том числе стеков потоков. Однако эти
  две функции уничтожают потоки
  принудительно так, будто для каждого
  из них вызывается функция TerminateThread.
  А это означает,
  что очистка проводится некорректно,
  деструкторы С++-объектов не вызываются,
  данные на диск не сбрасываются и т. д.

• Действия
  при завершении потока

• Управление
  динамическими приоритетами потока:

• BOOL
  SetThreadPriorityBoost(

• HANDLE
  hThread,          
  // дескриптор потока

• BOOL
  DisablePriorityBoost
  // состояние форсирования приоритета

• );

• BOOL
  GetThreadPriorityBoost(

• HANDLE
  hThread,            
  // дескриптор
  потока

• PBOOL
  pDisablePriorityBoost // состояние
  форсажа
  //приоритета

• );

• Поток
  должен иметь право доступа
  THREAD_SET_INFORMATION.

• Управление
  потоками:

• Флаг
  CREATE_SUSPENDED

• Если поток создан
  с флагом CREATE_SUSPENDED, то после своего
  создания он остается в приостановленном
  состоянии. Вы можете настроить некоторые
  его свойства (например, приоритет, о
  котором мы поговорим позже). Закончив
  настройку, Вы должны разрешить выполнение
  потока. Для этого вызовите ResumeThread
  и пере дайте
  описатель потока, возвращенный функцией
  CreateThread.

• DWORD ResumeThread(HANDLE
  hThread);

• Выполнение потока
  можно приостановить не только при его
  создании с флагом CREATE_SUSPENDED, но и вызовом
  SuspendThread.
  Выполнение
  отдельного потока можно приостанавливать
  несколько раз. Если поток приостановлен
  3 раза, то и возобновлен он должен быть
  тоже 3 раза — лишь тогда система выделит
  ему процессорное время.

• DWORD
  SuspendThread(HANDLE hThread);

• Засыпание
  и
  переключение
  потоков

• VOID
  Sleep
  ( DWORD dwMilliseconds );

• Эта функция
  приостанавливает поток па dwMilliseconds
  миллисекунд.
  Отметим несколько важных моментов,
  связанных с функцией Sleep.

• Вызывая
  Sleep, поток
  добровольно отказывается от остатка
  выделенного ему кванта времени

• Система прекращает
  выделять потоку процессорное время
  на период, пример
  но равный
  заданному, Все верно: если Вы укажете
  остановить поток на 100 мс, приблизительно
  на столько он и «заснет», хотя не
  исключено, что его сон про длится на
  несколько секунд или даже минут больше.
  Вспомните, Windows не является системой
  реального времени. Ваш поток может
  возобновиться в заданный момент, но
  это зависит от того, какая ситуация
  сложится в системе к тому времени.

• Вы
  можете вызвать Sleep
  и передать
  в dwMilliseconds
  значение
  INFINITE, вообще запретив планировать
  поток. Но это не очень практично — куда
  лучше корректно завершить поток,
  освободив его стек и объект ядра.

• Вы
  можете вызвать Sleep
  и передать
  в dwMilliseconds
  нулевое
  значение. Тогда Вы откажетесь от остатка
  своего кванта времени и заставите
  систему подключить к процессору другой
  поток. Однако система может снова
  запустить Ваш поток, если других
  планируемых потоков с тем же приоритетом
  нет.

• BOOL
  SwitchToThread();

• Функция
  SwitchToThread
  позволяет
  подключить к процессору другой поток
  (если он есть).

• Вызов
  SwitchToThread
  аналогичен
  вызову Sleep с
  передачей в
  dwMilliseconds
  нулевого
  значения. Разница лишь в том, что
  SwitchToThread дает
  возможность
  выполнять потоки с более низким
  приоритетом, которым не хватает
  процессорного времени, а Sleep
  действует
  без оглядки на «голодающие» потоки.

• Определение
  периодов выполнения потока:

• BOOL
  GetThreadTimes(

• HANDLE
  hThread,

• PFILETIME
  pftCreationTime,

• PFILETIME
  pftExitTime,

• PFILETIME
  pftKernelTime,

• PFILETIME
  pftUserTime

• );

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

• GetThreadTimes
  не годится
  для высокоточного измерения временных
  интервалов.

• Создание
  процесса:

• Вызов функции
  CreateProcess.

• Система создает
  объект ядра «процесс» с начальным
  значением счетчика числа его
  пользователей, равным 1. Этот объект –
  не сам процесс, а компактная структура
  данных, через которую ОС управляет
  процессом.

• Затем система
  создает для нового процесса виртуальное
  адресное пространство и загружает в
  него код и данные как для исполняемого
  файла, так и для любых DLL (если таковые
  требуются).

• Далее система
  формирует объект ядра «поток» (со
  счетчиком, равным 1) для первичного
  потока нового процесса. Как и в первом
  случае, объект ядра «поток» – это
  компактная структура данных, через
  которую система управляет потоком.

• Первичный поток
  начинает с исполнения стартового кода
  из библиотеки С/С++, который в конечном
  счете вызывает функцию WinMain
  или
  main в Вашей
  программе.

• Если системе удастся
  создать новый процесс и его первичный
  поток, CreateProcess
  вернет TRUE.

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

• BOOL
  CreateProcess
  (

• PCTSTR
  pszApplicationName, //
  имя
  исполняемого
  файла
  

• PTSTR
  pszCommandLine, //
  командная
  строка
  

• PSECURITY_ATTRIBUTES
  psaProcess,
  

• PSECURITY_ATTRIBUTES
  psaThread, //
  атрибуты
  защиты
  потоков
  

• BOOL
  bInheritHandles, //
  наследование
  дескрипторов
  

• DWORD
  fdwCreate, //
  флаги
  

• PVOID
  pvEnvironment,
  // блок
  памяти, хранящий строки переменных

• окружения
  

• PCTSTR
  pszCurDir,
  // текущий
  диск и каталог для процесса

• PSTARTUPINFO
  psiStartInfo,
  // используется
  Windows-функциями
  при

• создании
  нового процесса

• PPROCESS_INFORMATION
  ppiProcInfo //
  инициализируемая
  структура
  

• );

• Параметры
  CreateProcess:

• Параметры
  pszApplicationName и
  pszCommandLine. Эти
  параметры определяют имя исполняемого
  файла, которым будет пользоваться
  новый процесс, и командную строку,
  передаваемую этому процессу.

• Параметры
  psaProcess, psaThread и
  blnheritHandles . Параметры
  psaProcess и
  psaThread позволяют
  определить нужные атрибуты защиты для
  объектов «процесс» и «поток»
  соответственно. В эти параметры можно
  занести NULL, и система закрепит за
  данными объектами дескрипторы защиты
  по умолчанию.

• Параметр fdwCreate
  определяет
  флаги, влияющие на то, как именно
  создается новый процесс Флаги
  комбинируются булевым оператором OR.

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

• Параметр
  pszCurDir позволяет
  родительскому процессу установить
  текущие диск и каталог для дочернего
  процесса. Если его значение — NULL,
  рабочий каталог нового процесса будет
  тем же, что и у приложения, его породившего.

• Параметр
  psiStartlnfo указывает
  на структуру STARTUPINFO. Элементы структуры
  STARTUPINFO используются Windows-функциями при
  создании нового процесса.

• Параметр
  ppiProclnfo указывает
  на структуру PROCESS_INFORMATION, которую Вы
  должны предварительно создать; ее
  элементы инициализируются самой
  функцией CreateProcess.

• Параметр fdwCreate
  определяет
  флаги, влияющие на то, как именно
  создается новый процесс

• Флаги
  комбинируются булевым оператором OR.

• Флаг DEBUG_PROCESS даст
  возможность родительскому процессу
  проводить отладку дочернего, а также
  всех процессов, которые последним
  могут быть порождены.

• Флаг
  DEBUG_ONLY_THIS_PROCESS аналогичен флагу
  DEBUG_PROCESS с тем исключением, что заставляет
  систему уведомлять родительский
  процесс о возникновении специфических
  событий только в одном дочернем процессе
  — его прямом потомке.

• Флаг CREATE_SUSPENDED
  позволяет создать процесс и в то же
  время приостановить его первичный
  поток Это позволяет родительскому
  процессу модифицировать содержимое
  памяти в адресном пространстве
  дочернего, изменять приоритет его
  первичного потока или включать этот
  процесс в задание (job) до того, как он
  получит шанс на выполнение. Внеся
  нужные изменения в дочерний процесс,
  родительский разрешает выполнение
  его кода вызовом функции ResumeThread.

• Флаг DETACHED_PROCESS
  блокирует доступ процессу, инициированному
  консольной программой, к созданному
  родительским процессом консольному
  окну и сообщает системе, что вывод
  следует перенаправить в новое консольное
  окно.

• Флаг CREATE_NEW_CONSOLE
  приводит к созданию нового консольного
  окна для нового процесса. Имейте в
  виду, что одновременная установка
  флагов CREATE_NEW_CONSOLE
  и DETACHED_PROCESS
  недопустима.

• Флаг CREATE_NO_WINDOW не
  дает создавать никаких консольных
  окон для данного приложения и тем самым
  позволяет исполнять его без
  пользовательского интерфейса.

• Флаг
  CREATE_BREAKAWAY_FROM_JOB позволяет процессу,
  включенному в задание, создать новый
  процесс, отделенный от этого задания

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

• Idle
  (простаивающий)
  IDLE_PRIORITY_CLASS

• Below normal
  (ниже
  обычного)
  BELOW_NORMAL_PRIORITY_CLASS

• Normal
  (обычный)
  NORMAL_PRIORITY_CLASS

• Above normal
  (выше
  обычного)
  ABOVE_NORMAL_PRIORITY_CLASS

• High
  (высокий)
  HIGH_PRIORITY_CLASS

• Realtime
  (реального
  времени)
  REALTIME_PRIORITY_CLASS

• Классы приоритета
  влияют на распределение процессорного
  времени между процессами и их потоками.

• Классы приоритета
  BELOW_NORMAL_PRIORITY_CLASS и ABOVE_NORMAL_ PRIORITY_CLASS введены
  лишь в Windows 2000; они не поддерживаются
  в Windows NT 4.0, Windows 95 или Windows 98.

• Завершение
  процесса:

• Существует 4
  гипотетических варианта завершения
  процесса:

• —
  входная функция первичного потока
  возвращает управление (рекомендуемый
  способ);

• —
  один из потоков процесса вызывает
  функцию ExitProcess
  (нежелательный
  способ);

• —
  поток другого процесса вызывает функцию
  TerminateProcess
  (тоже
  нежелательно);

• —
  все потоки процесса умирают (большая
  редкость).

• Явный вызов
  ExitProcess
  и TerminateProcess –
  распространенная ошибка, которая
  мешает правильной очистке ресурсов.

• Возврат управления
  входной функцией первичного потока

• При
  этом:

• —
  любые С++-объекты, созданные данным
  потоком, уничтожаются соответствующими
  деструкторами;

• —
  система освобождает память, которую
  занимал стек потока;

• —
  система устанавливает код завершения
  процесса (поддерживаемый объектом
  ядра «процесс») – его и возвращает
  Ваша входная функция;

• —
  счетчик пользователей данного объекта
  ядра «процесс» уменьшается на 1.

• Функция
  ExitProcess:

• Процесс
  завершается, когда один из его потоков
  вызывает ExitProcess:

• VOID ExitProcess(UINT
  fuExitCode);

• Эта
  функция завершает процесс и заносит
  в параметр fuExitCode
  код завершения процесса.

• Функция
  TerminateProcess:

• Вызов
  функции TerminateProcess
  тоже завершает
  процесс:

• BOOL
  TerminateProcess (HANDLE hProcess, UINT fuExitCode);

• Параметр
  bProcess
  идентифицирует
  описатель завершаемого процесса, а в
  параметре fuExitCode
  возвращается код завершения процесса.

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

• Когда
  все потоки процесса “уходят”

• Обнаружив, что в
  процессе не исполняется ни один поток,
  операционная система немедленно
  завершает его.

• При этом код
  завершения процесса приравнивается
  коду завершения последнего потока.

• Действия
  при завершении процесса:

Ниже представлена не простая расшифровка доклада с семинара 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 планировщик). Режим вытесняющей многозадачности является приоритетным, т.к. решает, что будет исполняться на основе приоритетов. Почему так? Потому что у каждого потока есть свой приоритет и операционная система планирует к исполнению более приоритетные потоки. А вытесняющей потому, что если возникает более приоритетный поток, он вытесняет тот, который сейчас исполнялся. Однако во многих случаях это бы означало, что часть потоков никогда не доберется до исполнения. Поэтому в операционной системе есть много механик, позволяющих потокам, которым необходимо время на исполнение его получить несмотря на свой более низкий по сравнению с остальными, приоритет.

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

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. Это значения — так называемые уровни насыщения.

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

У нас бал класс приоритета процесса 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 (столбик с квадратиками):

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

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

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

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

Рассмотрим, как в системе Windows осуществляется планирование потоков для их выполнения на центральном процессоре. Также посмотрим на приоритеты процессов и потоков.

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

В Windows всегда выполняется хотя бы один поток с самым высоким приоритетом. Если в системе много ядер, то Windows делит все ядра на группы по 64 ядра. Каждому процессу даётся доступ к определённой группе ядер. Следовательно потоки этих процессов могут видеть только свою группу ядер.

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

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

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

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

Планирование осуществляется на уровне потоков, а не процессов. Например, Процесс_А имеет 10 потоков, а Процесс_Б – 2 потока. Тогда процессорное время распределился между этими 12 потоками равномерно.

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

Планирование потоков полагается на их приоритеты. Windows использует 32 уровня приоритета для потоков от 0 до 31:

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

Вначале поток получает свой Базовый приоритет, который наследуется от приоритета процесса:

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

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

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

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

Изменить базовый приоритет процесса можно из “Диспетчера задач” на вкладке “Подробности“, или в “Process Explorer“. Однако, это не поменяет относительный приоритет потока.

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

Получается что относительный приоритет у потока Notepad.exe равен 2, так как динамический приоритет больше базового на 2.

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

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

• Готов (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/0». Выберите ее, щелкните на кнопке «Добавить» (Add), а затем щелкните на кнопке «ОК».
7. Как только вы щелкните мышкой по блокноту, то заметите в Системном мониторе, что приоритет у потока «Блокнот» поднялся до 12, если свернуть блокнот то приоритет вновь упадет до 10.

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

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

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

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

Термины группового планирования:

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

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

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

Вернуться к оглавлению

������������ ��������� ���������� ��� �������� ������������� �������

������������ ��������� ���������� ��� �������� ������������� �������

����������� ���� ����� ��������: ����� � ����������� 7 ��������� ��������� ����� � ����������� 4, �� ����� ��� ����������� �������� ������������ �����; ��� ���� ����� � ����������� 11 ������� �����-�� ������, ��������������� ������� � ����������� 4. Ho, ��������� ����� � ����������� 7 �������� ��� ������������ �����, ����� � ����������� 4 ������� �� ������� ������������ �����, ����������� ��� ���������� � ������������ ��������, ������ ������ � ����������� 11. ��� �� ������ Windows � �������� ��������? ��� � ������� ��������� ��������� ������� (balance set manager), ��������� �����, ��������������� ������� ������� ��� ���������� ������� ���������� ������� (��. ����� 7), ��������� ������� ������� ������� � ���� ������, ������� ��������� � ��������� Ready � ������� �������� 4 ������. ��������� ����� �����, ��������� ��������� ������� �������� ��� ��������� �� 15. B Windows 2000 � Windows XP ����� ������ ����������� ������������ ������ ��������. B Windows Server 2003 ����� ��������������� ������ 4 ��������. ��� ������ ����� ��������, ��������� ������ ���������� ��������� �� ��������� ������. ���� ���� ����� �� ����� ��������� ���� ������ � ���� ������ ����� � ����� ������� ����������� ����� � ����������, �� ����� �������� ���������� �� ������������ � ������� ������� �������. B ����� ����� 4 ������� ��� ��������� ����� ���� ����� �������.

Ha ����� ���� ��������� ��������� ������� �� ��������� ��� ������ ������� ��� ������, ������� � ����������. ����� ������ � �������� ������ ������������� �������, �� ��������� ���� 16 ������� �������. ���� ����� ������� � ������ ������� ���������� ����� 16, �� ���������� ��� �����, ����� ������� �� �����������, � � ��������� ��� ���������� ������������ ������ � ����. ����� ����, �� �������� ��������� �� ����� ��� � 10 ������� �� ���� ������. ��������� 10 �������, ��������� ������� ������� �������� (��� ������� � ���������� ������� ������������� �������), �� ���������� ������������. ��� ��������� ������� ������������ �������������� � ���� �����, ��� ��� ���� �������� � ������� ���.

������ �� ������ �������� ������ ��������, ��������� � ������������? ����� ��� � �� ���� �� ����������. Ho �� �������� ������, ���������� �� �������� ������������� �������, ����������� �������� �����, ����������� ��� ���������� ��������� ������� ������ � �������� � ��������� ��������.

�����������: ������������ ��������� ����������� ��� �������� ������������� �������

������� CPU Stress (��� ������ � ������ �������� � Platform SDK) ��������� ���������, ��� �������� �������� ������������� ��������� �����������. B ���� ������������ �� ������, ��� ���������� ������������� ������������� ���������� ��� ��������� ���������� ������. ��� ����� ���������� ��������� ��������. 1. ��������� Cpustres.exe. �������� �������� � ������ Activity ��� ��������� ������ (�� ��������� � Thread 1) � Low �� Maximum. ����� ������� ��������� ������ � Normal �� Below Normal. ��� ���� ���� ������� ������ ��������� ���:

2.���������� Windows NT 4 Performance Monitor (Perfmon4.exe �� �������-����� �������� Windows 2000). ��� ����� ����������� ��� ���������� ������, ��������� ��� ����������� �������� ��������� ����, ��� ��� � �������.

3.��������� �� ������ ������������ ������ Add Counter (��� ������� ������� Ctrl+I), ����� ������� ���������� ���� Add To Chart.

4.��������� ������ Thread � ������� % Processor Time.

5.������������ ������ Instance � ������� ������� Cpustres. �������� ������ ����� ��� ������� 1, ��� ��� ������ (��� ������� 0) �������� ������� GUI.

6.��������� ������ Add, ����� � ������ Done.

7.���������� ��������� Performance Monitor �� ������ ��������� �������. ��� ����� ��������� Task Manager (��������� �����) � �������� ������� Perfmon4.exe �� ������� Processes (��������). �������� ��� �������� ������ ������� ����, �������� Set Priority (���������) � ������� Realtime (��������� �������). ��� ���� �� �������� �������������� � ����������� ������������ ������ ������� � �������� ������ Yes (��).

8.���������� ��� ���� ��������� CPU Stress. �������� � ��� �������� Activity ��� Thread 1 � Low �� Maximum.

9.������� ������������� ������� � Performance Monitor. �� ������ ��������� �������� ���������� ���������� �������� ������ 4 �������, ��� ��� ��������� ������ ������ �� 15.

�������� �����������, �������� Performance Monitor � ��� ���������� CPU Stress.

�����������: �������������� ������������� ��������� ����������

����� ���������� ������ ������������� ��������� ���������� ������ ��� �������� ������������� �������, � ������� �� �������� ������ ��������� ��������� ��������.

1.���������� Windows Media Player (��� ������ ��������� ��� ��������������� ������) � �������� �����-������ ����������� ����.

2.���������� Cpustres �� �������� Windows 2000 � ������� ��� ������ 1 ������������ ������� ����������.

3.��������� ��������� ������ 1 � Normal �� Time Critical.

4.���������������� ������ ������ ������������, ��� ��� ����������, ����������� �������, ��������� ��� ������������ �����.

5.������ �� ������� �� ������ ������� ���������� ����� ������, ����� ��������� ������������ ������ � ��������, ������� ������������� ����������� ����, ����������� ���������� �� 15 � �� �������� ������� �� �������� ����� ������ ������.

6.��������� Cpustres � Windows Media Player.

Real-time is the highest priority class available to a process. Therefore, it is different from ‘High’ in that it’s one step greater, and ‘Above Normal’ in that it’s two steps greater.

Similarly, real-time is also a thread priority level.

The process priority class raises or lowers all effective thread priorities in the process and is therefore considered the ‘base priority’.

So, a process has a:

1. Base process priority class.
2. Individual thread priorities, offsets of the base priority class.

Since real-time is supposed to be reserved for applications that absolutely must pre-empt other running processes, there is a special security privilege to protect against haphazard use of it. This is defined by the security policy.

In NT6+ (Vista+), use of the Vista Multimedia Class Scheduler is the proper way to achieve real-time operations in what is not a real-time OS. It works, for the most part, though is not perfect since the OS isn’t designed for real-time operations.

Microsoft considers this priority very dangerous, rightly so. No application should use it except in very specialized circumstances, and even then try to limit its use to temporary needs.

Real-time is the highest priority class available to a process. Therefore, it is different from ‘High’ in that it’s one step greater, and ‘Above Normal’ in that it’s two steps greater.

Similarly, real-time is also a thread priority level.

The process priority class raises or lowers all effective thread priorities in the process and is therefore considered the ‘base priority’.

So, a process has a:

1. Base process priority class.
2. Individual thread priorities, offsets of the base priority class.

Since real-time is supposed to be reserved for applications that absolutely must pre-empt other running processes, there is a special security privilege to protect against haphazard use of it. This is defined by the security policy.

In NT6+ (Vista+), use of the Vista Multimedia Class Scheduler is the proper way to achieve real-time operations in what is not a real-time OS. It works, for the most part, though is not perfect since the OS isn’t designed for real-time operations.

Microsoft considers this priority very dangerous, rightly so. No application should use it except in very specialized circumstances, and even then try to limit its use to temporary needs.