Эффективный и современный С++. 42 рекомендации по использованию С++11 и С++14 - [106]

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

Ваша жизнь станет легче, если вы переложите свои проблемы на чужие плечи, и это плечо вам готов подставить std::async:

auto fut = std::async(doAsyncWork); // Управление потоками лежит
                                    // на реализации стандартной
                                    // библиотеки

Этот вызов переносит ответственность за управление потоками на реализацию стандартной библиотеки С++. Например, вероятность получения исключения нехватки потоков значительно снижается, поскольку этот вызов, вероятно, никогда его не сгенерирует. “Как такое может быть? — удивитесь вы. — Если я запрошу больше потоков, чем может предоставить система, то какая разница, как это будет сделано — через создание std::thread или вызовом std::async?” Это имеет значение, поскольку std::async, будучи вызвана в данном виде (т.e. со стратегией запуска по умолчанию; см. раздел 7.2), не гарантирует создания нового программного потока. Она скорее разрешает планировщику организовать для указанной функции (в нашем примере — doAsyncWork) возможность запуска потоком, запрашивающим результат doAsyncWork (например, в потоке, вызывающем get или wait для объекта fut), и интеллектуальные планировщики воспользуются предоставленной свободой, если в системе превышена подписка или не хватает потоков.

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

При применении std::async время отклика потока GUI может остаться проблематичным, поскольку планировщику неизвестно, какой из ваших потоков имеет повышенные требования к этому параметру. В таком случае вы можете захотеть передать в std::async стратегию запуска std::launch::async. Это гарантирует, что интересующая вас функция будет действительно выполнена другим потоком (см. раздел 7.2).

Современные планировщики потоков во избежание превышения подписки используют пулы потоков всей системы и повышают балансировку загрузки между аппаратными ядрами с помощью специальных алгоритмов. Стандарт С++ не требует применения пулов потоков или конкретных алгоритмов, и, честно говоря, есть некоторые технические аспекты спецификации параллельности в С++11, которые делают его применение более трудным, чем хотелось бы. Тем не менее некоторые производители используют преимущества указанных методов в своих реализациях стандартной библиотеки, и следует ожидать продолжения прогресса в данной области. Если вы примете для параллельного программирования подход на основе задач, вы будет автоматически пользоваться ее преимуществами, которые будут возрастать с ее распространенностью. С другой стороны, программируя непосредственно с помощью std::thread, вы берете на себя бремя борьбы с исчерпанием потоков, превышением подписки и балансировкой загрузки (не упоминая уже о том, насколько ваши решения этих проблем будут совместимы с решениями в программах, работающих в других процессах на том же компьютере).

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

• Вам нужен доступ к API, лежащей в основе реализации потоков. В С++ API параллельных вычислений обычно реализуется с помощью низкоуровневого платформо-зависимого API, обычно pthreads или Windows Threads. Эти API в настоящее время предлагают больше возможностей, чем С++. (Например, С++ не имеет понятий приоритетов или родственности потоков.) Для предоставления доступа к API реализации потоков std::thread обычно предлагает функцию-член native_handle