Читать онлайн «Системное программирование в среде Windows». Страница 78

Резюме

Применение синхронизации может отрицательно воздействовать на производительность как в однопроцессорных, так и в 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. 

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

Первое, что нам предстоит сделать — это объединить два или более объекта синхронизации вместе с данными для создания сложного объекта синхронизации. Наиболее полезной комбинацией такого рода является модель переменных условий (condition variable model), включающая мьютекс и одно или несколько событий. Указанная модель играет весьма существенную роль в самых различных практических ситуациях, поскольку многие серьезные программные дефекты, обусловленные влиянием состязательности, проявляются именно тогда, когда объекты синхронизации Windows, особенно события, используются программистами неправильно. События имеют сложную природу и ведут себя по-разному в зависимости от того, какой именно из описанных в табл. 8.1 вариантов используется, и поэтому следует придерживаться определенных правил, устанавливаемых хорошо изученными моделями.

В последующих разделах показано, как систематизировать управление запуском и отменой выполнения каждого из совместно работающих потоков при помощи асинхронного вызова процедур (Asynchronous Procedure Calls, APC).

Другие проблемы производительности обсуждаются по мере необходимости.

Многопоточные программы намного легче разрабатывать, делать их более понятными и сопровождать, если использовать известные, хорошо разработанные методики и модели. Эти вопросы уже обсуждались в главе 7, в которой для создания полезной концептуальной основы, позволяющей понять принципы работы многопоточных программ, были введены модель "хозяин/рабочий" ("boss/worker") и модель рабочей группы (work crew model). Понятие критических участков кода (critical sections) играет существенную роль при использовании мьютексов, а определение инвариантов (invariants) используемых структур данных также может принести немалую пользу. Наконец, даже для дефектов существуют свои модели, как это было показано на примере взаимной блокировки (deadlock) потоков.

Примечание

Компания Microsoft разработала собственный набор моделей, таких как апартаментная модель (apartment model) или модель свободных потоков (free threading). Эта терминология чаще всего встречается в технологии СОМ и кратко обсуждается в конце главы 11.

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

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

• Мьютекс определяет критический участок кода для доступа к объекту структуры данных.

• Событие используется для того, чтобы сигнализировать о появлении нового сообщения.

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

• Один поток (в программе 8.2 — поток производителя) блокирует структуру данных, изменяет состояние объекта путем создания нового сообщения и применяет функции SetEvent или PulseEvent к событию, связанному с появлением нового сообщения.

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

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