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

Ваша жизнь станет легче, если вы переложите свои проблемы на чужие плечи, и это плечо вам готов подставить 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. Такая функциональность отсутствует в std::future (т.e. в том, что возвращает std::async).

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