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

. Такая функциональность отсутствует в std::future  (т.e. в том, что возвращает std::async).

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

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

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

Следует запомнить

• API std::thrеаd не предлагает способа непосредственного получения возвращаемых значений из асинхронно выполняемых функций, и, если такие функции генерируют исключения, программа завершается.

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

• Программирование на основе задач с помощью std::async со стратегией запуска по умолчанию решает большинство перечисленных проблем вместо вас.

7.2. Если важна асинхронность, указывайте >std::launch::async

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

• стратегияstd::launch::async означает, что f должна выполняться асинхронно, т.e. в другом потоке;

• стратегияstd::launch::deferred означает, что f может выполняться только тогда, когда для фьючерса, возвращенного std::async, вызывается функция-член get или wait[22], т.e. выполнение fоткладывается до тех пор, пока не будет выполнен такой вызов. Когда вызываются функции-члены get или wait, функция f выполняется синхронно, т.e. вызывающая функция блокируется до тех пор, пока f не завершит работу. Если не вызывается ни get, ни wait, f не выполняется.

Возможно, это окажется удивительным, но стратегия запуска std::async по умолчанию — используемая в случае, если вы не указали таковую — не является ни одной из перечисленных. На самом деле это стратегия, которая представляет собой сочетание описанных с помощью оператора “или”. Два приведенных далее вызова имеют один и тот же смысл:

auto fut1 = std::async(f); // Выполнение f со стратегией
                           // запуска по умолчанию

auto fut2 = std::async(    // Выполнение f
 std::launch::async |      // асинхронное
 std::launch:: deferred,   // или отложенное
 f);

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

Но применение std::async со стратегией запуска по умолчанию имеет некоторые интересные последствия. Для потока t, выполняющего приведенную ниже инструкцию, справедливы следующие утверждения.

auto fut = std::async(f); // Выполнение f со стратегией
                          // запуска по умолчанию

• Невозможно предсказать, будет лиfвыполняться параллельно сt, поскольку выполнение f может быть отложено планировщиком.

• Невозможно предсказать, будет лиfвыполняться потоком, отличным от того, в котором вызываются функции-членыgetилиwaitобъектаfut. Если этот поток — t, отсюда вытекает невозможность предсказать, будет ли f выполняться потоком, отличным от t.

• Может быть невозможно предсказать, будет лиfвыполнена вообще, поскольку может оказаться невозможно гарантировать, что функции-члены get или wait объекта fut будут вызваны на всех путях выполнения программы.

Гибкость планирования стратегии запуска по умолчанию часто плохо комбинируется с использованием переменных thread_local, поскольку она означает, что если f читает или записывает такую локальную память потока (thread-local storage — TLS), то невозможно предсказать, к переменным какого потока будет обращение:

auto fut = std::async(f); // TLS для f может принадлежать
                          // независимому потоку, но может
                          // принадлежать и потоку, вызывающему
                          // get или wait объекта fut

Это также влияет на циклы на основе wait с использованием тайм-аутов, поскольку вызов wait_for или wait_until для откладываемой задачи (см. раздел 7.1) дает значение std::future_status::deferred. Это означает, что приведенный далее цикл, который выглядит как в конечном итоге завершающийся, может оказаться бесконечным: