Реализация потоков в windows

Вопрос 20. Планирование потоков в ос Windows.

Приоритеты

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

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

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

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

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

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

• выше
нормы
(ABOVE_NORMAL_PRIORITY_CLASS),

• нормальный
(NORMAL_PRIORITY_CLASS),

• ниже
нормы
(BELOW_NORMAL_PRIORITY_CLASS)

• и
неработающий
(IDLE_PRIORITY_CLASS).

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

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

Таблица 8.1.
Формирование базового приоритета потока
из класса приоритета процесса и
относительного приоритета потока

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

Классы приоритетов
процессов Критичный ко времени Самый
высокий Выше нормы Нормальный Ниже
нормы Самый низкий Неработающий

Неработающий 15 6 5 4 3 2 1

Ниже нормы 15 8 7 6 5 4 1

Нормальный 15 10 9 8 7 6 1

Выше
нормы 15 12 11 10 9 8 1

Высокий 15 15 14 13 12 11 1

Реального
времени 31 26 25 24 23 22 16

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

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

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

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

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

Другими примерами
подобных ситуаций могут служить:
пробуждение потока после состояния
ожидания семафора или иного события;
получение потоком доступа к оконному
вводу.

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

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

Прогон программы,
демонстрация приоритетного планирования

#include <windows.h>

#include
<stdio.h>

#include
<math.h>

void
Calculations()

{

int
I,N=50000000;

double a,b;

for ( I =
0; i<N; i++) {

b=(double)I
/ (double)N;

a=sin(b);

}

}

DWORD
WINAPI SecondThread( LPVOID lpParam )

{

printf(“Begin
of Second Thread\n”);

Calculations();

printf(“End
of Second Thread\n”);

return 0;

}

VOID main(
VOID )

{

DWORD
dwThreadId, dwThrdParam;

HANDLE
hThread;

hThread =
CreateThread(

NULL,

0,

SecondThread,

&dwThrdParam,

0,

&dwThreadId);

if
(hThread == NULL)

{

printf(“CreateThread
failed\n” );

return;

}

SetThreadPriority(hThread,
THREAD_PRIORITY_ABOVE_NORMAL);

SuspendThread(hThread);

getchar();

ResumeThread(hThread);

printf(“Begin
of First Thread\n”);

Calculations();

printf(“End
of First Thread\n”);

}

В приведенной
программе два параллельных потока
выполняют длительный счетный цикл
(подпрограмма Calculations). Второй поток в
силу более высокого приоритета выполняется
раньше. Пара функций Suspend/ResumeThread
(приостановка и возобновление потока)
используется для фиксации начала
соревнования. Если закомментировать
SetThreadPriority, то можно будет увидеть, что
оба потока заканчивают работу одновременно.

В качестве
самостоятельного упражнения рекомендуется
реализовать более гибкие сценарии
планирования, например, с добавлением
функций SwitchToThread (передача управления
потоку), или Sleep (приостановка потока в
течение заданного промежутка времени).
В MSDN имеется описание множества полезных
функций, связанных с планированием
потоков.

Величина кванта
времени

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

По умолчанию
начальная величина кванта в Windows
Professional равна двум интервалам таймера,
а в Windows Server эта величина увеличена до
12, чтобы свести к минимуму переключение
контекста. Длительность интервала
таймера определяется HAL и составляет
примерно 10 мс для однопроцессорных x86
систем и 15 мс – для многопроцессорных.
Величину интервала системного таймера
можно определить с помощью свободно
распространяемой утилиты Clockres (сайт
sysinternals.com).

Выбор между
короткими и длинными значениями можно
сделать с помощью панели «свойства»
«Моего компьютера». Величина
кванта
задается
в
параметре
HKLM\SYSTEM\CurrentControlSet\Control\PriorityControl\Win32PrioritySeparation
реестра.

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

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

Ниже представлена не простая расшифровка доклада с семинара 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, в котором мы с огромным удовольствием будем говорить про практику работы с многопоточным кодом. Будут и домашние задания и даже возможность работы с личным ментором.

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

Понятие процесса и потока

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

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

Для описания столь сложного динамического объекта ОС поддерживает набор структур, главную из которых принято называть блоком управления процессом (PCB, Process control block). В состав PCB обычно включают:

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

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

Потоки

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

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

Реализация процессов

Внутреннее устройство процессов в ОС Windows

В 32-разрядной версии системы у каждого процесса есть 4-гигабайтное адресное пространство, в котором пользовательский код занимает нижние 2 гигабайта (в серверах 3 Гбайта). В своем адресном пространстве, которое представляет собой набор регионов и описывается специальными структурами данных (см. часть III «система управления памятью»), процесс содержит потоки, учетную информацию и ссылки на ресурсы, которые обобществляются всеми потоками процесса.

Блок управления процессом (PCB) реализован в виде набора связанных структур, главная из которых называется блоком процесса EPROCESS. Соответственно, каждый поток также представлен набором структур во главе с блоком потока ETHREAD. Эти наборы данных, за исключением блоков переменных окружения процесса и потока (PEB и TEB), существуют в системном адресном пространстве. Упрощенная схема структур данных процесса показана на
рис.
5.2.

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

Рис.
5.2.
Управляющие структуры данных процесса

Содержимое блока EPROCESS подробно описано в
[
Руссинович
]
. Блок KPROCESS (на рис. справа), блок переменных окружения процесса (PEB) и структура данных, поддерживаемая подсистемой Win32 (блок процесса Win32), содержат дополнительные сведения об объекте «процесс».

Идентификатор процесса кратен четырем и используется в роли байтового индекса в таблицах ядра наравне с другими объектами.

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

Обычно процесс создается другим процессом вызовом Win32-функции CreateProcess (а также CreateProcessAsUser и CreateProcessWithLogonW ). Создание процесса осуществляется в несколько этапов.

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

На втором этапе выполняется обращение к системному сервису NtCreateProcess для создания объекта «процесс». Формируются блоки EPROCESS, KPROCESS и блок переменных окружения PEB. Менеджер процессов инициализирует в блоке процесса маркер доступа (копируя аналогичный маркер родительского процесса), идентификатор и другие поля.

На третьем этапе в уже полностью проинициализированном объекте «процесс» необходимо создать первичный поток. Это, посредством системного сервиса NtCreateThread, делает библиотека kernel32.dll.

Затем kernel32.dll посылает подсистеме Win32 сообщение, которое содержит информацию, необходимую для выполнения нового процесса. Данные о процессе и потоке помещаются, соответственно, в список процессов и список потоков данного процесса, затем устанавливается приоритет процесса, создается структура, используемая той частью подсистемы Win32, которая работает в режиме ядра, и т.д.

Наконец, запускается первичный поток, для чего формируются его начальный контекст и стек, и выполняется запуск стартовой процедуры потока режима ядра KiThreadStartup. После этого стартовый код из библиотеки C/C++ передает управление функции main() запускаемой программы.

В книге
[
Руссинович
]
этапы создания процесса описаны более подробно.

Функция CreateProcess

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

BOOL CreateProcess( 
  PCTSTR pszApplicationName, 
  PTSTR pszCommandLine, 
  PSECURITY_ATTRIBUTES psaProcess, 
  PSECURITY_ATTRIBUTES psaThread, 
  BOOL bInheritHandles, 
  DWORD fdwCreate, 
  PVOID pvEnvironment,
  PCTSTR pszCurDir, 
  PSTARTUPINFO psiStartInfo, 
  PPROCESS_INFORMATION ppiProcInfo);

Описание параметров функции можно посмотреть в MSDN.

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

Источник статьи

Автор24
— учеба по твоим правилам

Введение

Бывают ситуации, когда специалисту требуется одновременно исполнять несколько задач, используя одно приложение. Чтобы решить эту и другие подобные проблемы, можно использовать средства, которые дают возможность реализации многопоточности. Многопоточность может быть использована в следующих случаях:

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

Использование потоков в приложениях Windows

Следует отметить, что не все версии Windows были способны в полной мере работать в полнопоточном режиме, даже при поддержке оборудованием такого режима. Например, Windows 95 была способна лишь имитировать режим многопоточности.

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

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

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

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

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

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

Для использования объектов потоков в своём приложении, пользователь должен сформировать потомок класса TThread. Этот класс был спроектирован, чтобы облегчить формирование приложений, имеющих несколько потоков. Он обеспечивает совместимость при использовании библиотеки визуальных компонентов (VCL) Delphi.

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

1. Избегать создания чрезмерно большого количества потоков, поскольку это ведёт к перегрузке операционной системы и процессора. Рекомендуется создавать для однопроцессорной системы не более шестнадцати активных потоков в одном процессе.
2. Использовать синхронизацию в ситуации, когда сразу несколько потоков стремятся обеспечить себе доступ к одному и тому же ресурсу.
3. Почти все методы, которые выполняют обращение к объектам VCL и меняют содержание формы, обязаны получать вызов из главного потока или применять объект синхронизации.

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

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

Приоритет всех потоков состоит из следующих компонентов:

1. Класс приоритета, то есть приоритет процесса, который породил поток.
2. Относительный приоритет, то есть приоритет самого потока.

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

Чтобы определить текущий и установить требуемый класс приоритета применяются соответственно функции Get Prioriry Class и Set Priority Class.

Работа операционной системы Windows основана на работе процессов. В этой статье разберём что такое Windows процессы, их свойства, состояния и другое.

Процессы

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

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

Windows процессы состоят из следующего:

• Закрытое виртуальное адресное пространство, то есть выделенная для процесса часть оперативной памяти, которая называется виртуальной.
• Исполняемая программа выполняя свой код, помещает его в виртуальную память.
• Список открытых дескрипторов. Процесс может открывать или создавать объекты, например файлы или другие процессы. Эти объекты нумеруются, и их номера называют дескрипторами. Ссылаться на объект по дескриптору быстрее, чем по имени.
• Контекст безопасности. Сюда входит пользователь процесса, группа, привилегии, сеанс и другое.
• Идентификатор процесса, то есть его уникальный номер.
• Программный поток (как минимум один или несколько). Чтобы процесс хоть что-то делал, в нем должен существовать программный поток. Если потока нет, значит что-то пошло не так, возможно процесс не смог корректно завершиться, или стартовать.

У процессов есть еще очень много свойств которые вы можете посмотреть в «Диспетчере задач» или «Process Explorer«.

Процесс может быть в различных состояниях:

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

В Windows существуют процессы трёх типов:

• Приложения. Процессы запущенных приложений. У таких приложений есть окно на рабочем столе, которое вы можете свернуть, развернуть или закрыть.
• Фоновые процессы. Такие процессы работают в фоне и не имеют окна. Некоторые процессы приложений становятся фоновыми, когда вы сворачиваете их в трей.
• Процессы Windows. Процессы самой операционной системы, например «Диспетчер печати» или «Проводник».

Дерево процессов

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

Например у нас есть такое дерево процессов:

Процесс_1
|- Процесс_2
  |- Процесс_3

Если мы завершим дерево процессов «Процесс_1«, то завершатся все процессы. Потому что «Процесс_1» знает про «Процесс_2«, а «Процесс_2» знает про «Процесс_3«.

Если мы вначале завершим «Процесс_2«, а затем завершаем дерево процессов «Процесс_1«, то завершится только «Процесс_1«, так как между «Процесс_1» и «Процесс_3» не останется связи.

Например, запустите командную строку и выполните команду title parrent чтобы изменить заголовок окна и start cmd чтобы запустить второе окно командной строки:

>title parrent
>start cmd

Измените заголовок второго окна на child и из него запустите программу paint:

>title child
>mspaint

В окне командной строке child введите команду exit, окно закроется а paint продолжит работать:

>exit

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

Запустите «Диспетчер задач», на вкладке «Процессы» найдите процесс «Обработчик команд Windows», разверните список и найдите «parrent«. Затем нажмите на нём правой копкой мыши и выберите «Подробно»:

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

Вы переключитесь на вкладку «Подробно» с выделенным процессом «cmd.exe«. Нажмите правой кнопкой по этому процессу и выберите «Завершить дерево процессов»:

Окно командной строки Parrent завершится а Paint останется работать. Так мы убедились что связи между первым процессом и его внуком нет, если у внука нет непосредственного родителя.

Потоки

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

Поток содержит:

• два стека: для режима ядра и для пользовательского режима;
• локальную памятью потока (TLS, Thread-Local Storage);
• уникальный идентификатор потока (TID, Thread ID).

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

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

• svchost.exe — главный процесс для служб Windows.
• dllhost.exe — отвечает за обработку приложений, использующих динамически подключаемые библиотеки. Также отвечает за COM и .NET. И ещё управляет процессами IIS.
• lsass.exe — отвечает за авторизацию локальных пользователей, попросту говоря без него вход в систему для локальных пользователей будет невозможен.

Волокна и планирование пользовательского режима

Потоки выполняются на центральном процессоре, а за их переключение отвечает планировщик ядра. В связи с тем что такое переключение это затратная операция. В Windows придумали два механизма для сокращения таких затрат: волокна (fibers) и планирование пользовательского режима (UMS, User Mode Scheduling).

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

Потоки UMS (User Mode Scheduling), доступные только в 64-разрядных версиях Windows, предоставляют все основные преимущества волокон при минимуме их недостатков. Потоки UMS обладают собственным состоянием ядра, поэтому они «видимы» для ядра, что позволяет нескольким потокам UMS совместно использовать процессор и конкурировать за него. Работает это следующим образом:

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

Задания

Задания Windows (Job) позволяют объединить несколько процессов в одну группу. Затем можно этой группой управлять:

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

Посмотреть на задания можно с помощью Process Explorer.

Диспетчер задач

Чаще всего для получения информации о процессе мы используем «Диспетчер задач». Запустить его можно разными способами:

• комбинацией клавиш Ctrl+Shift+Esc;
• щелчком правой кнопкой мыши на панели задач и выборе «Диспетчер задач»;
• нажатием клавиш Ctrl+Alt+Del и выборе «Диспетчер задач»;
• запуском исполняемого файла C:\Windows\system32\Taskmgr.exe.

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

В полном режиме на вкладке «Процессы» виден список процессов и информация по ним. Чтобы получить больше информации можно нажать правой кнопкой мышки на заголовке и добавить столбцы:

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

Чтобы получить еще больше информации можно нажать правой кнопкой мышки на процессе и выбрать «Подробно». При этом вы переключитесь на вкладку «Подробности» и этот процесс выделится.

На вкладке «Подробности» можно получить ещё больше информации о процессе. А также здесь также можно добавить колонки с дополнительной информацией, для этого нужно щелкнуть правой кнопкой мыши по заголовку и нажать «Выбрать столбцы»:

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

Process Explorer

Установка и подготовка к работе

Более подробную информацию о процессах и потоках можно получить с помощью программы Process Explorer из пакета Sysinternals. Его нужно скачать и запустить.

Некоторые возможности Process Explorer:

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

Запустите Process Explorer:

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

Далее нужно настроить сервер символических имен. Если это не сделать, при двойном щелчке на процессе, на вкладке Threads (потоки) вы получите сообщение о том, что символические имена не настроены:

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

Для начала скачиваем установщик «Пакет SDK для Windows 10».

Устанавливать все не нужно, достаточно при установки выбрать «Debugging Tools for Windows«:

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

Для настройки символических имен перейдите в меню Options / Configure / Symbols. Введите путь к библиотеке Dbghelp.dll, которая находится внутри установленного «Пакета SDK для Windows 10» по умолчанию:

• C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\Dbghelp.dll.

И путь к серверу символической информации:

• srv*C:\Symbols*http://msdl.microsoft.com/download/symbols

При этом:

• C:\Symbols — путь к кеширующей локальной папке;
• http://msdl.microsoft.com/download/symbols — сервер microsoft.

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

Некоторые основные настройки Process Explorer:

• Смена цветового выделения — Options / Configure Colors.
• Выбор колонок с информацией о процессах — View / Select Columns.
• Сортировка процессов — нужно щелкнуть на заголовке столбца Process, при первом щелчке сортировка будет в алфавитном порядке, при втором в обратном порядке, при третьем вернется в вид дерева.
• Просмотр только своих процессов — View / снять галочку Show Processes from All Users.
• Настройка времени выделения только что запущенных процессов и завершённых — Options / Difference Highlight Duration / введите количество секунд.
• Чтобы исследователь процесс подробнее можно дважды щелкнуть на нем и посмотреть информацию на различных вкладках.
• Открыть нижнюю панель для просмотра открытых дескрипторов или библиотек — Vies / Show Lower Panel.

Потоки в Process Explorer

Потоки отдельного процесса можно увидеть в программе Process Explorer. Для этого нужно дважды кликнуть по процессу и в открывшемся окне перейти на вкладку «Threads»:

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

В колонках видна информация по каждому потоку:

• TID — идентификатор потока.
• CPU — загрузка процессора.
• Cycles Delta — общее количество циклов процессора, которое этот процесс использовал с момента последнего обновления работы Process Explorer. Скорость обновления программы можно настроить, указав например 5 минут.
• Suspend Count — количество приостановок потока.
• Service — название службы.
• Start Address — начальный адрес процедуры, который начинает выполнение нового потока. Выводится в формате:«модуль!функция».

При выделении потока, снизу показана следующую информация:

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

• Идентификатор потока.
• Время начала работы потока.
• Состояние потока.
• Время выполнения в режиме ядра и в пользовательском режиме.
• Счетчик переключения контекста для центрального процессора.
• Количество циклов процессора.
• Базовый приоритет.
• Динамический приоритет (текущий).
• Приоритет ввода / вывода.
• Приоритет памяти.
• Идеальный процессор (предпочтительный процессор).

Есть также кнопки:

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

• Stack — посмотреть стек процесса;
• Module — посмотреть свойства запущенного исполняемого файла;
• Permission — посмотреть права на поток;
• Kill — завершить поток;
• Suspend — приостановить поток.

Задания в Process Explorer

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

Более того, страницы свойств таких процессов содержат дополнительную вкладку Job с информацией о самом объекте задания. Например приложение Skype работает со своими процессами как за заданием:

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

Запустите командную строку и введите команду:

>runas /user:<домен>\<пользователь> cmd

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

В новой командной строке запустите блокнот:

>notepad.exe

Далее запускаем Process Explorer и находим такое дерево процессов:

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

Как видим, процесс cmd и notepad это процессы связанные с каким-то заданием. Если дважды кликнуть по любому из этих процессов и перейти на вкладку Job, то мы увидим следующее:

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

Тут видно что эти два процесса работают в рамках одного задания.

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

Если понравилась статья, подпишись на мой канал в VK или Telegram.