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

Учет факторов производительности при организации управленияпамятью

Программа 9.1, приведенная в следующей главе, позволяет исследовать различные аспекты производительности в условиях, когда несколько потоков соревнуются между собой за право обладания разделяемыми ресурсами. Аналогичные эффекты будут наблюдаться и в случае, когда потоки привлекаются для управления памятью с использованием функций malloc и free из многопоточной стандартной библиотеки С, поскольку эти функции используют объекты CRITICAL_SECTION для синхронизации доступа к структуре данных кучи (вы можете в этом сами убедиться, просмотрев исходный код библиотеки С). Ниже описаны два возможных способа улучшения производительности.

• Каждый поток, управляющий памятью, может создать дескриптор типа HANDLE для собственной кучи с помощью функции HeapCreate (глава 5). После этого для распределения памяти вместо функций malloc и free можно использовать функции HeapAlloc и HeapFree.

• Значение переменной окружения времени выполнения __MSVCRT_HEAP_SELECT можно установить равным __GLOBAL_HEAP_SELECTED. Это приведет к тому, что функции malloc и free будут использовать для управления памятью схему Windows, которая использует спин-блокировки (spin locks) вместо объектов CS и может быть намного более эффективной. Этот метод был предложен Гербертом Орашем (Gerbert Orasche) в статье "Configuring VC++ Multithreaded Memory Management", опубликованной в майском выпуске журнала Windows Developer's Journal за 2000 год, а представленные в этой статье результаты убедительно свидетельствуют о преимуществах данного метода в отношении производительности.

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

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

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

Ранее уже упоминались другие книги, посвященные синхронизации в Windows. В то же время, при чтении книг по Windows более общего характера следует быть очень внимательными, поскольку в том, что касается потоков и синхронизации, некоторые из них могут попросту дезориентировать, и большинство из них не были обновлены с целью включения в рассмотрение средств NT5, которые мы используем в данной книге. Так, в одной очень популярной книге, получившей положительные отзывы рецензентов, несмотря на большой объем содержащихся в ней словесных описаний, ни слова не говорится о классе памяти volatile, не совсем правильно объяснены четыре модели событий, а в качестве метода, позволяющего изменить значение счетчика семафора более чем на единицу, рекомендуется решение, в котором используются многократные вызовы функций ожидания, что чревато возникновением взаимоблокировок (вспомните обсуждение в разделе, посвященном семафорам).

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

8.1.  На Web-сайте книги находится версия программы simplePC.c (программа 8.1), содержащая дефекты, которая называется simplePCx.c. Проверьте работу этой программы и опишите симптомы дефектов, если они проявляются. Внесите в программу необходимые исправления, не сверяясь с правильным решением.

8.2. Измените программу simplePC.c таким образом, чтобы промежуток времени между генерацией новых сообщений увеличился. (Подсказка. Уберите операцию деления в том месте программы, где вызывается функция sleep.) Убедитесь в правильности логики, определяющей наличие новых сообщений. Кроме того, самостоятельно поэкспериментируйте с программой simplePCx.с, содержащей дефекты.

8.3. Переделайте программу simplePC. с, задействовав в ней мьютексы.

8.4. Переделайте программу sortMT.c (программа 7.2), использовав для синхронизации запуска рабочих потоков не приостановку потоков, а семафор.

8.5. Переделайте программу sortMT.c (программа 7.2), использовав для синхронизации запуска рабочих потоков не приостановку потоков, а события. В рекомендуемом решении используется функция SetEvent и сбрасываемое вручную событие. Другие комбинации не могли бы гарантировать корректную работу программы. Дайте этому свои объяснения.

8.6. Поэкспериментируйте с программой 8.2, используя различные комбинации автоматически и вручную сбрасываемых событий, а также функций SetEvent и PulseEvent (в текущем решении используются функция SetEvent и автоматически сбрасываемое событие). Могут ли считаться корректными альтернативные и исходный варианты реализации с учетом объявленного функционального назначения программы? (См. примечание после программы 8.2.) Объясните результаты и поясните, в чем с функциональной точки зрения состоит полезность альтернативных вариантов реализации. Можете ли вы добиться того, чтобы заработали альтернативные варианты реализации, изменив логику программы? 

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

8.8. Упражнение повышенной сложности. Объекты CRITICAL_SECTION предназначены для использования потоками в рамках одного и того же процесса. Что произойдет, если объект CS будет создан в разделяемой отображаемой области памяти? Смогут ли использовать CS оба процесса? Вы можете провести самостоятельный эксперимент, изменив программу таким образом, чтобы производитель и потребитель выполнялись в различных процессах.  

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

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