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

Программные потоки являются ограниченным ресурсом. Если вы попытаетесь создать их больше, чем может предоставить система, будет сгенерировано исключение std::system_error. Это так, даже если функция, которую вы хотите запустить, не генерирует исключений. Например, даже если doAsyncWorkобъявлена как noexcept,

int doAsyncWork() noexcept; // См. noexcept в разделе 3.8

следующая инструкция может сгенерировать исключение:

std::thread t(doAsyncWork); // Генерация исключения, если

// больше нет доступных потоков

Хорошо написанное программное обеспечение должно каким-то образом обрабатывать такую возможность, но как? Один вариант — запустить doAsyncWorkв текущем потоке, но это может привести к несбалансированной нагрузке и, если текущий поток является потоком GUI, к повышенному времени реакции системы на действия оператора. Другой вариант — ожидание завершения некоторых существующих программных потоков с последующей попыткой создания нового объекта std::thread, но может быть и так, что существующие потоки ожидают действий, которые должна выполнить функция doAsyncWork(например, ее результата или уведомления переменной условия).

Даже если вы не исчерпали потоки, у вас могут быть проблемы с превышением подписки (oversubscription). Это происходит, когда имеется больше готовых к запуску (т.e. незаблокированных) программных потоков, чем аппаратных. Когда это случается, планировщик потоков (который обычно представляет собой часть операционной системы) выполняет разделение времени для выполнения программных потоков аппаратными. Когда время работы одного потока завершается и начинается время работы второго, выполняется переключение контекстов. Такие переключения контекстов увеличивают накладные расходы по управлению потоками и могут оказаться в особенности дорогостоящими, когда аппаратный поток, назначаемый программному, оказывается выполняемым другим ядром, не тем, что ранее. В этом случае (1) кеши процессора обычно оказываются с данными, не имеющими отношения к данному программному потоку, и (2) запуск “нового” программного потока на этом ядре “загрязняет” кеши процессора, заполняя их данными, не имеющими отношения к “старым” потокам, которые выполнялись этим ядром и, вероятно, будут выполняться им снова.

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

Ваша жизнь станет легче, если вы переложите свои проблемы на чужие плечи, и это плечо вам готов подставить 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. возвращаемых значений или исключений). Тем не менее существуют ситуации, в которых применение потоков может быть более подходящим. Они включают в себя следующее.