Рихтер Дж., Назар К. - Windows via C C++. Программирование на языке Visual C++ - 2009

250 Часть II. Приступаем к работе

CStopwatch stopwatch;

__int64 реrfCountStart = stopwatch.NowInMicro();

// получаем текущее число тактов

unsigned __int64 cyclesOnStart = ReadTimeStampCounter();

//ожидаем в течение 1 с

Sleep(1000);

//получаем число тактов по истечении 1 с

unsigned __int64 numberOfCycles = ReadTimeStampCounter() - cyclesOnStart;

// измеряем прошедшее время более точно

elapsedTime = stopwatch.NowInMicro() - perfCountStart;

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

SetThreadPriority(GetCurrentThread(), currentPriority);

//вычисляем частоту процессора в МГц

DWORD dwCPUFrequency = (DWORD)(numberOfCycles / elapsedTime); return(dwCPUFrequency);

}

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

Структура CONTEXT

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

Вы, Наверное, удивитесь, но в документации Platform SDK структуре CONTEXT отведен буквально один абзац:

«В структуре CONTEXT хранятся данные о состоянии регистров с учетом специфики конкретного процессора. Она используется системой для выполнения различных внутренних операций? Соответствующие определения см. в заголовочном файле WinNT.h.»

Глава 7. Планирование потоков, приоритет и привязка к процессорам.docx 251

В документации нет ни слова об элементах этой структуры, набор которых зависит от lima процессора. Фактически CONTEXT — единственная из всех структур Windows, специфичная для конкретного процессора.

Так из чего же состоит структура CONTEXT? Давайте посмотрим. Ее элементы четко соответствуют регистрам процессора. Например, для процессоров х86 в число элементов входят Еах, Ebx, Есх, Edx и т. д. Структура CONTEXT для процессоров x86 выглядит так:

typedef struct _CONTEXT {

//

//Флаги, управляющие содержимым записи CONTEXT.

//Если запись контекста используется как входной параметр, тогда раздел,

//управляемый флагом (когда он установлен), считается содержащим

//действительные значения. Если запись контекста используется для

//модификации контекста потока, то изменяются только те разделы, для

//которых флаг установлен.

//

//Если запись контекста используется как входной и выходной параметр

//для захвата контекста потока, возвращаются только те разделы контекста,

//для которых установлены соответствующие флаги. Запись контекста никогда

//не используется только как выходной параметр.

//

DWORD ContextFlags;

//

//Этот раздел определяется/возвращается, когда в ContextFlags установлен

//флаг CONTEXT_DEBUG_REGISTERS. Заметьте, что CONTEXT_DEBUG_REGISTERS

//не включаются в CONTEXT_FULL.

//

//Этот раздел определяется/возвращается, когда в ContextFlags

//установлен флаг CONTEXT_FLOATING_POINT.

//

FLOATING_SAVE_AREA FloatSave;

252 Часть II. Приступаем к работе

//

//Этот раздел определяется/возвращается, когда в ContextFlags

//установлен флаг CONTEXT_SEGMENTS.

//

DWORD SegGs;

DWORD SegFs;

DWORD SegEs;

DWORD SegDs;

//

//Этот раздел определяется/возвращается, когда в ContextFlags

//установлен флаг CONTEXT_INTEGER.

//

DWORD Edl;

DWORD Esi;

DWORD Ebx;

DWORD Edx;

DWORD Ecx;

DWORD Eax;

//

//Этот раздел определяется/возвращается, когда в ContextFlags

//установлен флаг CONTEXT_CONTROL.

//

//Этот раздел определяется/возвращается, когда в ContextFlags

//установлен флаг COMTEXT_EXTENDED_REGISTERS.

//Формат и смысл значений зависят от типа процессора.

//

BYTE ExtendedRegistere[MAXIMUM_SUPPORTED_EXTENSION;]

} CONTEXT;

Эта структура разбита на несколько разделов. Раздел CONTEXT_ CONTROL содержит управляющие регистры процессора: указатель команд, указатель стека, флаги и адрес возврата функции. Раздел CONTEXT_

Глава 7. Планирование потоков, приоритет и привязка к процессорам.docx 253

INTEGER соответствует целочисленным регистрам процессора, CONTEXT_ FLOATING_POINT — регистрам с плавающей точкой, CONTEXT_SEGMENTS — сегментным регистрам, CONTEXT_DEBUG_REGISTERS — регист-

рам, предназначенным для отладки, a CONTEXT_EXTENDED_REGISTERS — дополнительным регистрам.

Windows фактически позволяет заглянуть внутрь объекта ядра «поток» и получить сведения о текущем состоянии регистров процессора. Для этого предназначена функция:

BOOL GetThreadContext(

HANDLE hThread,

PCONTEXT pContext);

Чтобы вызвать ее, создайте экземпляр структуры CONTEXT, инициализируйте нужные флаги (в элементе ContextFlags) и передайте функции GetThreadContext адрес этой структуры. Функция поместит значения в элементы, сведения о которых вы запросили.

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

Единственный элемент структуры CONTEXT, которому не соответствует ка- кой-либо регистр процессора, — ContextFlags. Присутствуя во всех вариантах этой структуры независимо от типа процессора, он подсказывает функции GetThreadContext, значения каких регистров вы хотите узнать. Например, чтобы получить значения управляющих регистров для потока, напишите что-то вроде:

//создаем экземпляр структуры CONTEXT CONTEXT Context;

//Сообщаем системе, что нас интересуют сведения

//только об управляющих регистрах.

Context.ContextFlags = CONTEXT_CONTROL;

//Требуем от системы информацию

//о состоянии регистров процессора для данного потока.

GetThreadContext(hThread, AContext);

//Действительные значения содержат элементы структуры CONTEXT,

//соответствующие управляющим регистрам, остальные значения

//не определены.

254 Часть II. Приступаем к работе

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

//Сообщаем системе, что нас интересуют

//управляющие и целочисленные регистры.

Context.ContextFlags = CONTEXT_CONTROL | CONTEXT_INTEGER;

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

//Сообщаем системе, что нас интересуют

//управляющие и целочисленные регистры.

Context.ContextFlags = CONTEXT_FULL;

CONTEXT_FULL определен в файле WinNT.h, как CONTEXT_CONTROL CONTEXT_INTEGER | CONTEXT_SEGMENTS.

После возврата из GetThreadContext вы легко проверите значения любых регистров для потока, но помните, что такой код зависит от типа процессора. Так, у процессоров типа х86 в поле Eip хранится указатель на сегмент команд, а в поле Esp — указатель на стек.

Даже удивительно, какой мощный инструмент дает Windows в руки разработчика! Но есть вещь, от которой вы придете в полный восторг: значения элементов CONTEXT можно изменять и передавать объекту ядра «поток» с помощью функ-

ции SetThreadContext.

BOOL SetThreadContext(

HANDLE hThread,

CONST CONTEXT *pContext);

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

Прежде чем обращаться к SetThreadContext, инициализируйте элемент ContextFlags, как показано ниже.

CONTEXT Context;

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

SuspendThread read(hThread);

//получаем регистры для контекста потока

Context.ContextFlags = C0NTEXT_C0NTROL; GetThreadContext(hThread, &Context);

//устанавливаем указатель команд по своему выбору;

//в нашем примере присваиваем значение 0x00010000 Context.Eip = 0x00010000;

//вносим изменения в регистры потока; ContextFlags

//можно и не инициализировать, так как это уже сделано

Глава 7. Планирование потоков, приоритет и привязка к процессорам.docx 255

Context.ContextFlags = CONTEXT_CONTROL;

SetThreadContext(hThread, &Context);

//возобновляем выполнение потока;

//оно начнется с адреса 0x00010000 ResumeThread(hThread);

Этот код, вероятно, приведет к ошибке защиты (нарушению доступа) в удаленном потоке; система сообщит о необработанном исключении, и удаленный процесс будет закрыт. Все верно — не ваш, а удаленный. Вы благополучно обрушили другой процесс, оставив свой в целости и сохранности!

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

Подробнее о структуре CONTEXT мы поговорим в главе 24.

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

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

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

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

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

256 Часть II. Приступаем к работе

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

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

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

Абстрагирование приоритетов

Создавая планировщик потоков, разработчики из Майкрософт прекрасно понимали, что он не подойдет на все случаи жизни. Они также осознавали, что со временем «назначение» компьютера может измениться. Например, в момент выпуска Windows NT создание приложений с поддержкой OLE еще только начиналось. Теперь такие приложения — обычное дело. Кроме того, значительно расширилось применение игрового программного обеспечения, ну и, конечно же, Интернета.

Алгоритм планирования потоков существенно влияет на выполнение приложений. С самого начала разработчики Майкрософт понимали, что его придется изменять по мере того, как будут расширяться сферы применения компьютеров. Майкрософт гарантирует, что наши программы будут работать и в следующих версиях Windows. Как же ей удается изменять внутреннее устройство системы, не нарушая работоспособность наших программ? Дело в том, что:

■планировщик документируется не полностью;

■Майкрософт не разрешает в полной мере использовать все особенности планировщика;

■Майкрософт предупреждает, что алгоритм работы планировщика постоянно меняется, и не рекомендует писать программы в расчете на текущий алгоритм.

Глава 7. Планирование потоков, приоритет и привязка к процессорам.docx 257

Windows API предоставляет слой абстрагирования от конкретного алгоритма работы планировщика, запрещая прямое обращение к планировщику. Вместо этого вы вызываете функции Windows, которые «интерпретируют» ваши параметры в зависимости от версии системы. Я буду рассказывать именно об этом слое абстрагирования.

Проектируя свое приложение, вы должны учитывать возможность параллельного выполнения других программ. Следовательно, вы обязаны выбирать класс приоритета, исходя из того, насколько «отзывчивой» должна быть ваша программа. Согласен, такая формулировка довольно туманна, но так и задумано: Майкрософт не желает обещать ничего такого, что могло бы нарушить работу вашего кода в будущем.

Windows поддерживает шесть классов приоритета: idle (простаивающий), below normal (ниже обычного), normal (обычный), above normal (выше обычного), high (высокий) и realtime (реального времени). Самый распространенный класс приоритета, естественно, — normal; его использует 99% приложений. Классы приоритета показаны в следующей таблице.

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

Класс приоритета high следует использовать лишь при крайней необходимости. Классом приоритета real-time почти никогда не стоит пользоваться. На самом деле в ранних бета-версиях Windows NT 3.1 присвоение этого класса приоритета приложениям даже не предусматривалось, хотя операционная система поддерживала эту возможность. Real-time — чрезвычайно высокий приоритет, и, поскольку большинство потоков в системе (включая управляющие самой системой) имеет более низкий приоритет, процесс с таким классом окажет на них сильное влияние. Так, потоки реального времени могут заблокировать необходимые операции дискового и сетевого ввода-вывода и привести к несвоевременной обработке ввода от мыши и клавиатуры — пользователь может подумать, что система зависла. У вас должна быть очень веская причина для применения класса real-time — например, программе требуется реагировать на события в аппаратных средствах с минимальной задержкой или выполнять быстротечную операцию, которую нельзя прерывать ни при каких обстоятельствах.

258 Часть II. Приступаем к работе

Табл. 7-2. Классы приоритета процессов

Примечание. Процесс с классом приоритета real-time нельзя запустить, если пользователь не имеет привилегии Increase Scheduling Priority. По умолчанию такой привилегией обладает администратор и опытный пользователь.

Конечно, большинство процессов имеет обычный класс приоритета. В Windows 2000 появилось два новых промежуточных класса — below normal и above normal. Майкрософт добавила их, поскольку некоторые компании жаловались, что существующий набор классов приоритетов не дает должной гибкости.

Выбрав класс приоритета, забудьте о том, как ваша программа будет выполняться совместно с другими приложениями, и сосредоточьтесь на ее потоках. Windows поддерживает семь относительных приоритетов потоков: idle (Простаивающий), lowest (низший), below normal (ниже обычного), normal (обычный), above normal (выше обычного), highest (высший) и time-critical (критичный по времени). Эти приоритеты относительны классу приоритета процесса. Как обычно, большинство потоков использует обычный приоритет. Относительные приоритеты потоков описаны в таблице 7-3.

Итак, вы присваиваете процессу некий класс приоритета и можете изменять относительные приоритеты потоков в пределах процесса. Заметьте, что я не сказал ни слова об уровнях приоритетов 0-31. Разработчики прило-

Глава 7. Планирование потоков, приоритет и привязка к процессорам.docx 259

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

Табл. 7-3. Приоритеты потоков

В таблице 7-4 показано, как формируется уровень приоритета в Windows Vista, но не забывайте, что в Windows NT и тем более в Windows 95/98 этот механизм действует несколько иначе. Учтите также, что в будущих версиях Windows он вновь изменится.

Например, обычный поток в обычном процессе получает уровень приоритета 8. Поскольку большинство процессов имеет класс normal, а большинство потоков — относительный приоритет normal, у основной части потоков в системе уровень приоритета равен 8.

Обычный поток в процессе с классом приоритета high получает уровень приоритета 13. Изменив класс приоритета процесса на idle, вы снизите уровень приоритета того же потока до 4. Вспомните, что приоритет потока всегда относителен классу приоритета его процесса. Изменение класса приоритета процесса не влияет на относительные приоритеты его потоков, но сказывается на уровне их приоритета.