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

std::thread t(doAsyncWork);

Вы также можете передать doAsyncWork в std::async, воспользовавшись стратегией, известной как подход на основе задач:

auto fut = std::async(doAsyncWork); // "fut" от "future"

В таких вызовах функциональный объект, переданный в std::async (например, doAsyncWork), рассматривается как задача (task).

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

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

• Аппаратные потоки являются потоками, которые выполняют фактические вычисления. Современные машинные архитектуры предлагают по одному или по нескольку аппаратных потоков для каждого ядра процессора.

• Программные потоки (известные также как потоки ОС или системные потоки) являются потоками, управляемыми операционной системой[21] во всех процессах и планируемыми для выполнения аппаратными потоками. Обычно можно создать программных потоков больше, чем аппаратных, поскольку, когда программный поток заблокирован (например, при вводе-выводе или ожидании мьютекса или переменной условия), пропускная способность может быть повышена путем выполнения других, незаблокированных потоков.

• std::thread представляют собой объекты в процессе С++, которые действуют как дескрипторы для лежащих в их основе программных потоков. Некоторые объекты std::thread представляют “нулевые” дескрипторы, т.e. не соответствуют программным потокам, поскольку находятся в состоянии, сконструированном по умолчанию (следовательно, без выполняемой функции); потоки, из которых выполнено перемещение (после перемещения объект std::thread, в который оно произошло, действует как дескриптор для соответствующего программного потока); потоки, у которых выполняемая ими функция завершена; а также потоки, у которых разорвана связь между ними и обслуживающими их программными потоками.

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

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

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

std::thread t(doAsyncWork); // Генерация исключения, если
                            // больше нет доступных потоков

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

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