• Главная
• В избранное
• Наш E-MAIL
• Добавить материал
• Нашёл ошибку
• Вниз

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

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

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

Примечание

В NT 5.0 достигнут значительный прогресс в плане повышения производительности. В ранних версиях NT и в Windows 9x некоторые из отмеченных выше проблем носили гораздо более острый характер.

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

Прежде всего, мы попытаемся количественно оценить влияние объектов синхронизации на производительность, и сравним между собой объекты CRITICAL_SECTION и мьютексы. В программе statsMX.c (программа 9.1) для синхронизации доступа к специфической для каждого потока структуре данных используется мьютекс. Программа statsCS.c, листинг которой здесь не приводится, но его можно найти на Web-сайте книги, делает точно то же, но с использованием объекта CRITICAL_SECTION, тогда как в программе stats IN. с для этого привлекаются функции взаимоблокировки (interlocked functions). Наконец, в программе statsNS.с, которая также здесь не приводится, синхронизация вообще не используется; оказывается, в данном примере можно вообще обойтись без синхронизации, поскольку каждый рабочий поток обращается к собственной уникальной области памяти. Некоторые предостережения по этому поводу приведены в конце данного раздела. В реальных программах количество рабочих потоков может быть неограниченным, однако для простоты в программе 9.1 обеспечивается поддержка 64 потоков.

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

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

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

• В большинстве случаев использование мьютексов обеспечивают более высокое быстродействие программы по сравнению с использованием объектов CS.

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

/* Глава 9. statsMX.c */

/* Простая система "хозяин/рабочий", в которой каждый рабочий поток */

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

/* Версия, использующая мьютекс. */

#include "EvryThng.h"

#define DELAY_COUNT 20

/* Использование: statsMX nthread ntasks */

/* Запускается "nthread" рабочих потоков, каждой из которых поручается */

/* выполнение "ntasks" единичных рабочих заданий. Каждый поток сохраняет*/

/* информацию о выполненной работе в собственной неразделяемой ячейке */

/* массива, хранящего данные о выполненной потоком работе. */

DWORD WINAPI worker(void *);

typedef struct _THARG {

 int thread_number;

 HANDLE *phMutex;

 unsigned int tasks_to_complete;

 unsigned int *tasks_complete;

} THARG;

int _tmain(DWORD argc, LPTSTR argv[]) {

 INT tstatus, nthread, ithread;

 HANDLE *worker_t, hMutex;

 unsigned int* task_count, tasks_per_thread;

 THARG* thread_arg;

 /* Создать мьютекс. */

 hMutex = CreateMutex(NULL, FALSE, NULL);

 nthread = _ttoi(argv[1]);

 tasks_per_thread = _ttoi(argv[2]);

 worker_t = malloc(nthread * sizeof(HANDLE));

 task_count = calloc(nthread, sizeof(unsigned int));

 thread_arg = calloc(nthread, sizeof(THARG));

 for(ithread = 0; ithread < nthread; ithread++) {

  /* Заполнить данными аргумент потока. */

  thread_arg[ithread].thread_number = ithread; 

  thread_arg[ithread].tasks_to_complete = tasks_per_thread;

  thread_arg[ithread].tasks_complete = &task_count[ithread];

  thread_arg[ithread].phMutex = &hMutex;

  worker_t[ithread] = (HANDLE)_beginthreadex (NULL, 0, worker, &thread_arg[ithread], 0, &ThId);

 }

 /* Ожидать завершения рабочих потоков. */

 WaitForMultipleObjects(nthread, worker_t, TRUE, INFINITE);

 free(worker_t);

 printf("Выполнение рабочих потоков завершено\n");

 for (ithread = 0; ithread < nthread; ithread++) {

  _tprintf(_T("Количество заданий, выполненных потоком %5d: %6d\n"), ithread, task_count[ithread]);

 }

 return 0;

 free(task_count);

 free(thread_arg);

}

DWORD WINAPI worker(void *arg) {

 THARG * thread_arg;

 int ithread;

 thread_arg = (THARG*)arg;

 ithread = thread_arg->thread_number;

 while (*thread_arg->tasks_complete < thread_arg->tasks_to_complete) {

  delay_cpu(DELAY_COUNT);

  WaitForSingleObject(*(thread_arg->phMutex), INFINITE);

  (*thread_arg->tasks_complete)++;

  ReleaseMutex(*(thread_arg->phMutex));

 }

 return 0;

}

Для изучения поведения различных вариантов реализации можно воспользоваться программой timep из главы 6 (программа 6.2). Тесты, которые проводились на системах, не загруженных никакими другими задачами, и состояли в выполнении 250 000 единичных рабочих заданий с использованием 1,2,4, 8, 16, 32, 64 и 128 потоков, показали следующие результаты:

• При небольшом количестве потоков (4 и менее) для выполнения каждого из вариантов реализации NS (отсутствие синхронизации), IN (функции взаимоблокировки) и CS (объекты CRITICAL_SECTION) требуется примерно одно и то же время. Вариант CS может оказаться несколько более медленным (10-20 процентов), демонстрируя типичное замедление работы программ, использующих синхронизацию. Вместе с тем, для выполнения варианта MX (мьютексы) требуется в два-три раза больше времени. 

• Производительность варианта CS на однопроцессорных системах при использовании 5 и более потоков не всегда изменяется пропорционально количеству потоков. Картина может меняться при переходе от одной NT5-системы к другой, однако, как свидетельствуют данные, для каждой конкретной системы результаты согласуются между собой. В случае некоторых систем истекшее время удваивается при переходе к следующему члену ряда 1, 2, 4 и так далее, соответствующему количеству используемых потоков, но в одном случае (Windows 2000, процессор Pentium с частотой 1 ГГц, портативный компьютер) оно составляло (в секундах) 0.5, 1.0, 2.0, 4.0, 14.9, 16.0, 32.1 и 363.4, а в другом (Windows 2000, процессор Pentium 500 МГц, на стольный компьютер) — 1.2, 2.3, 4.7, 9.3, 42.7, 101.3, 207.8 и 1212.5 секунд. Как правило, резкое изменение поведения происходит тогда, когда количество потоков начинает превышать 4 или 8, но производительность остается приемлемой, пока количество потоков не превышает 128.

• В случае однопроцессорных систем вариант MX уступает варианту CS, причем отношение показателей производительности варьирует в пределах от 2:1 до 10:1 в зависимости от типа системы.

• В случае SMP-систем производительность может резко ухудшаться в десятки и сотни раз. Интуитивно кажется, что с увеличением количества процессоров производительность может только повышаться, но в силу механизмов внутренней реализации процессоры конкурируют между собой за право владения блокировками и обращения к памяти, и это объясняет, почему результаты для вариантов MX и CS оказываются практически одинаковыми. В случае объектов CS некоторого улучшения производительности удавалось добиться за счет тонкой настройки спин-счетчиков, о чем говорится в одном из следующих разделов.

• Для ограничения количества готовых к выполнению рабочих потоков без изменения базовой программной модели можно использовать семафоры. Эта методика рассматривается далее в этой главе.

Предупреждение

В массиве task_count намеренно использованы 32-битовые целые числа, чтобы увеличить верхний предел значений счетчика заданий и избежать создания предпосылок для возникновения "разрыва слов" ("word tearing") и "конфликтов строки кэша" ("cache line conflict") в SMP-системах. Два независимых процессора, на которых выполняются смежные рабочие потоки, могут одновременно изменять значения счетчиков смежных заданий путем внесения соответствующих изменений в свои кэши (32-битовые в системах на основе Intel x86). Вместе с тем, реально записываться в память будет только один кэш, что может сделать результаты недействительными. Чтобы избежать возможных рисков, следует позаботиться об отделении рабочих ячеек каждым из потоков друг от друга и их выравнивании в соответствии с размерами кэшей. В данном примере счетчик заданий может быть сгруппирован с аргументом потока, так что использованию 32-битовых счетчиков ничто не препятствует. Эта тема исследуется в упражнении 9.6. 

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

• Использование объектов CS или мьютексов.

• Глубина, или рекурсивность, счетчиков.

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

• Количество рабочих потоков, ограниченное системными ресурсами.

• Количество точек "засыпания" (sleep points), в которых рабочий поток уступает процессор, используя вызов Sleep(0), но продолжает владеть блокировкой. Точки "засыпания" моделируют ожидание рабочим потоком операций ввода/вывода или событий, тогда как задержка моделирует активность ЦП.

• Количество активных потоков, о чем говорится в разделе, посвященном дросселированию семафоров.

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

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

Примечание

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

Эффективность методики блокирования (вхождение в раздел) и разблокирования (выход из раздела) объекта CRITICAL_SECTION объясняется тем, что тестирование объекта CS выполняется в пользовательском пространстве без использования системных вызовов ядра, как это требуется в случае мьютексов. Снятие блокировки раздела также выполняется полностью в пространстве пользователя, в отличие от функции ReleaseMutex, которая требует использования системного вызова. Объекты CS работают следующим образом:

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

• Если обнаруживается, что объект CS блокирован, ECS входит в жесткий цикл (tight loop) на SMP-системах и выполняет многократное тестирование бита блокировки, не уступая процессора (разумеется, поток может быть вытеснен). Количество повторений цикла, после выполнения которых ECS прекращает дальнейшее тестирование, определяется значением спин-счетчика CS. В однопроцессорных системах тестирование прекращается немедленно; спин-счетчики используются лишь в случае SMP-систем.

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

• Функция LeaveCriticalSectibn реализуется путем выключения бита блокировки после проверки того, что вызывающий поток действительно является владельцем CS. Кроме того, ядро должно быть также уведомлено о том, существуют ли еще другие ожидающие потоки, для чего используется функции ReleaseSemaphore.

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

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

Спин-счетчики CS могут устанавливаться на стадии инициализации объектов CS или динамическим путем. В первом случае функция InitializeCriticalSection заменяется функцией InitializeCriticalSectionAndSpinCount, в которой добавлен параметр счетчика. В то же время, способа, позволяющего считать значение спин-счетчика, не существует.

VOID InitializeCriticalSectionAndSpinCount(LPCRITICAL_SECTION lpCriticalSection, DWORD dwCount)

 

Значение спин-счетчика можно в любой момент изменить. 

VOID SetCriticalSectionSpinCount(LPCRITICAL_SECTION lpCriticalSection, DWORD dwCount) 

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

На Web-сайте книги находится программа TimedMutualExclusionSC. Эта программа представляет собой видоизмененный вариант уже знакомой вам программы TimedMutualExclusion, в котором значение спин-счетчика указания в качестве параметра командной строки. Вы можете запустить эту программу на своей машине для приблизительной оценки того, какое значение спин-счетчика будет наиболее приемлемым для выполнения того или иного из вариантов тестовых программ на доступных вам SMP-системах, что и предлагается сделать в упражнении 9.2. 

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

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

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

• Каждый рабочий поток ожидает перехода семафора в сигнальное состояние, прежде чем войти в критический участок кода. Ожидание семафора может непосредственно предшествовать ожиданию мьютекса или объекта CS.

• Если максимальное значение счетчика семафора равно 1, то использование мьютекса становится излишним. Подобное решение нередко является наилучшим для SMP-систем. 

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

Счетчик семафора просто представляет число потоков, которые могут быть активными в любой момент времени, и ограничивает количество потоков, соревнующихся между собой за право владения мьютексом, объектом CS или иным ресурсом. Главный поток даже может регулировать, или, как говорят, "дросселировать" (throttle) выполнение рабочих потоков и динамически настраивать работу приложения, ожидая, пока не уменьшится значение счетчика, если он решает, что уровень состязательности слишком высок, или увеличивая значение счетчика с помощью функции ReleaseSemaphore, чтобы дать возможность выполняться большему количеству потоков. Заметьте, однако, что максимальное значение счетчика семафора устанавливается при его создании, и изменить его впоследствии невозможно.

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

while (TRUE) { // Рабочий цикл

 WaitForSingleObject(hThrottleSem, INFINITE);

 WaitForSingleObject(hMutex, INFINITE);

 … Критический участок кода …

 ReleaseMutex(hMutex);

 ReleaseSemaphore(hThrottleSem, 1, NULL);

} // Конец рабочего цикла

Можно предложить еще одну разновидность программы. Если некоторый рабочий поток потребляет "слишком много" ресурсов, то можно заставить его выжидать некоторое время, пока значение счетчика семафора не уменьшится на несколько единиц. Однако, как уже отмечалось в предыдущей главе, использование двух последовательных циклов ожидания может стать причиной взаимоблокировки (deadlock) потоков. В следующей главе в одном из упражнений (упражнение 10.11) показано, как построить сложный объект семафора, допускающий атомарное выполнение многократных функций ожидания.

В уже упоминавшемся примере программы TimedMutualExclusion добавлен шестой параметр, являющийся начальным значением дроссельного счетчика семафора для количества активных потоков. Вы можете поэкспериментировать со значениями этого счетчика, как предлагается в одном из упражнений. На рис. 9.1 показана зависимость различных временных характеристик для шести потоков, синхронизируемых посредством одного объекта CS, от количества активных потоков, изменяющегося в интервале от 1 до 6. Во всех случаях объем выполняемой работы остается одним и тем же, но истекшее время резко увеличивается, когда количество активных потоков превышает 4.

Рис. 9.1. Зависимость производительности от количества потоков

Указанные зависимости получены на устаревших, медленных системах. Для системы Windows 2000 на базе процессора Intel 586 (Pentium), характеризующейся гораздо более высоким быстродействием, соответствующие значения истекшего времени для 1–6 потоков составили (в секундах) 0.8, 0.8, 2.3, 21.2, 28.4 и 29.0, и эти результаты могут быть последовательно воспроизведены. В этом случае ухудшение производительности становилось заметным, начиная уже с 3 активных потоков. В то же время, соответствующие временные характеристики, оцененные с использованием произвольно выбранной совокупности аналогичных систем, оказались примерно постоянными, независимо от количества активных потоков. Результаты некоторых экспериментов дают основания сделать следующие выводы:

• В системе NT5 достигнут значительный прогресс по сравнению с NT4, по следовательно демонстрирующей результаты, аналогичные тем, которые представлены на рис. 9.1.

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

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

• В SMP-системах наиболее предпочтительным вариантом является дросселирование семафора при значении счетчика равном 1. В этом случае мьютексы становятся ненужными. Так, в случае двухпроцессорной системы Xeon частотой 1.8 ГГц использованные времена для варианта CS при 1, 2 и 4 активных потоках составили 1.8, 33.0 и 31.9 секунды. Соответствующие времена в случае мьютекса составили 34.0, 66.5 и 65.0 секунды.

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

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

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

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

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

• Различным процессорам можно назначать различные классы рабочих потоков.

У каждого процесса имеется собственная маска родства процесса (process affinity mask), представляющая собой битовый вектор. Существует также маска родства системы (system affinity mask). 

• Маска родства системы отображает процессоры, сконфигурированные в системе.

• Маска родства процесса отображает процессоры, на которых разрешается выполнение потоков данного процесса.

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

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

Для считывания как системных масок родства, так и масок родства процессов используется одна функция — GetProcessAffinityMask. В однопроцессорных системах, включая Windows 9x, все биты маски должны быть равными 1.

BOOL GetProcessAffinityMask(HANDLE hProcess, LPDWORD lpProcessAffinityMask, LPDWORD lpSystemAffinityMask)

 

Маска родства процесса, которая будет наследоваться любым дочерним процессом, устанавливается при помощи функции SetProcessAffinityMask. 

BOOL SetProcessAffinityMask(HANDLE hProcess, DWORD dwProcessAffinityMask)

 

В документации Microsoft говорится, что значение новой маски должно быть строгим подмножеством (proper subset) значений масок, получаемых с помощью функции GetProcessAffinityMask. Как показывает несложный эксперимент, включенный в код программы TimedMutualExclusion, новая маска может быть той же, что и маска системы или предыдущая маска процесса. Однако упомянутое ограничение не может быть справедливым, ибо в таком случае вы были бы лишены возможности восстанавливать маску родства системы до предыдущего значения.

В Windows 9x поддержка SMP, а также функций манипулирования масками процессов не поддерживаются. Новые значения масок влияют на все потоки, принадлежащие данному процессу. 

Для установки маски родства потоков применяется аналогичная функция. 

DWORD SetThreadAffinityMask(HANDLE hThread, DWORD dwThreadAffinityMask)

 

Типы возвращаемых значений этих функций не согласуются между собой. Типом возвращаемого значения функции SetThreadAffinityMask является DWORD, a не BOOL, но результат остается одним и тем же (1 — в случае успеха, 0 — в противном случае). Функция SetThreadAffinityMask работает и под управлением Windows 9х, но маска должна быть единичной, что не дает никакого прока. Кроме того, невзирая на документацию, новая маска не обязательно должна быть строгим подмножеством системной маски.

Функция SetThreadIdealProcessor является видоизменением функции SetThreadAffinityMask. Вы указываете предпочтительный ("идеальный") номер процессора (а не маску), и планировщик назначает потоку этот процессор, если такая возможность имеется, или назначит ему другой процессор, если предпочтительный процессор недоступен. Возвращаемым значением функции является номер предыдущего предпочтительного процессора, если таковой был назначен.

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

Процессоры Intel Pentium 4 и Xeon поддерживают механизм HyperThreading (гиперпотоки), посредством которого состояния ожидания, возникающие в процессе выполнения потока, используются для выполнения другого потока. Для поддержки этого средства используется второй регистровый файл, что вполне осуществимо, поскольку архитектура процессоров х8б характеризуется сравнительно небольшим количеством регистров. Xeon или любой другой процессор, поддерживающий гиперпоточную обработку, воспринимается функциями GetSystemInfo и GetProcessAffinityMask как одиночный процессор. 

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

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

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

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

• Блокирование потребляет значительные системные ресурсы; пользуйтесь этим средством лишь при настоятельной необходимости. Предоставляйте возможность удержания (владения) мьютекса или объекта CS строго в пределах лишь необходимого времени. Варьирование параметров задержки или точек "засыпания" демонстрирует снижение производительности с увеличением длительности периодов блокирования.

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

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

• Объекты CS предоставляют эффективный упрощенный механизм блокирования при небольшом количестве конкурирующих потоков, но в некоторых случаях мьютексы обеспечивают лучшую производительность. При использовании объектов CS в критических по отношению к производительности SMP-приложениях возможно настройка производительности с помощью спин-счетчиков.

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

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

• Заметное влияние на производительность оказывает также выбор модели — сигнальной или широковещательной, о чем более подробно говорится в главе 10.

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

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

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

Литературные источники, относящиеся также к данной главе, перечислены в главе 10.

9.1. Поэкспериментируйте с программой statsMX, используя для этого собственную систему, а также как можно большее количество других доступных вам систем, отличающихся друг от друга не только аппаратным обеспечением, но и версиями Windows. Аналогичны ли полученные вами результаты тем, о которых сообщалось в настоящей главе? Что наблюдается в случае SMP-систем?

9.2. Используйте функцию TimedMutualExclusionSC для экспериментальной проверки того, что путем изменения значений спин-счетчиков объектов CRITICAL_SECTION действительно можно улучшить производительность SMP-систем в случае большого количества потоков. Результаты могут меняться от системы к системе, однако практические эксперименты показали, что значения счетчиков, лежащие в интервале от 2000 до 10000, являются оптимальными.

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

9.4. Для ограничения количества выполняющихся потоков в функции TimedMutualExclusion наряду с другими средствами используется дросселирование семафоров. Поэкспериментируйте со значениями счетчиков как на однопроцессорных, так и на SMP-системах. Воспроизводят ли полученные вами результаты те, о которых сообщалось ранее в настоящей главе?

9.5. Воспользуйтесь методикой дросселирования семафоров в программе statsMX (statsCS.c, statsMX.с).

9.6. Упражнение повышенной сложности. Все ли из четырех разновидностей программы работают корректно, если не обращать внимания на производительность, на SMP-системах? Исследуйте результаты, получаемые при большом количестве потоков. Запустите программы на SMP-системах, работающих под управлением Windows 2000 или Windows Server 2003. Проявляются ли при этом проблемы "разрыва слов" ("word tearing") и "конфликтов строки кэша" ("cache line conflict"), описанных ранее в настоящей главе, а также в [6]? Для воспроизведения указанных проблем вам может потребоваться использование 16-битовых (тип данных short integer) счетчиков.

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

9.8. Постарайтесь определить, оказывает ли использование гиперпотоков влияние на производительность приложений. Средства гиперпоточной обработки обеспечиваются, например, процессором Intel Xeon.