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

std::thread t;

};

• Делайте std::threadнеподключаемыми на всех путях выполнения.

• Применение joinпри уничтожении объекта может привести к трудно отлаживаемым аномалиям производительности.

• Применение detachпри уничтожении объекта может привести к трудно отлаживаемому неопределенному поведению.

• Объявляйте объекты std::threadв списке членов-данных последними.

В разделе 7.3 вы узнали, что подключаемый std::threadсоответствует базовому системному потоку выполнения. Фьючерс для неотложенной задачи (см. раздел 7.2) имеет схожую связь с системным потоком. А раз так, и объекты std::thread, и объекты фьючерсов можно рассматривать как дескрипторы (handles) системных потоков.

С этой точки зрения интересно, что std::threadи фьючерсы совершенно по-разному ведут себя в деструкторах. Как упоминалось в разделе 7.3, уничтожение подключаемого std::threadзавершает работу программы, поскольку две очевидные альтернативы — неявный вызов joinи неявный вызов detach— оказываются еще более плохим выбором. Однако деструктор фьючерса ведет себя так, как если бы иногда выполнялся неявный вызов join, иногда — неявный вызов detach, а иногда — ни то и ни другое. Он никогда не приводит к завершению работы программы. Поведение этого дескриптора потока заслуживает более внимательного рассмотрения.

Начнем с наблюдения, что фьючерс представляет собой один из концов канала связи, по которому вызываемая функция передает результаты вызывающей [25] В разделе 7.5 поясняется, что разновидность канала связи фьючерса может быть использована и для других целей. Однако в этом разделе мы будем рассматривать только его применение в качестве механизма для передачи результата из вызываемой функции вызывающей. . Вызываемая функция (обычно работающая асинхронно) записывает результат вычислений в коммуникационный канал (обычно с помощью объекта std::promise), а вызывающая функция читает результат с помощью фьючерса. Вы можете представлять это для себя следующим образом (пунктирные стрелки показывают поток информации от вызываемой функции к вызывающей):

Но где же хранится результат вызываемой функции? Вызываемая функция может завершиться до того, как будет вызвана функция-член getсоответствующего фьючерса, так что результат не может быть сохранен в std::promiseвызываемой функции. Этот объект, будучи локальным по отношению к вызываемой функции, уничтожается по ее завершении.

Результат не может храниться и во фьючерсе вызывающей функции, поскольку (среди прочих причин) std::futureможет быть использован для создания объекта std::shared_future(тем самым передавая владение результатом вызываемой функции от std::futureв std::shared_future), который затем, после уничтожения исходного std::future, может быть многократно копирован. С учетом того, что не все типы результата могут быть скопированы (например, существуют только перемещаемые типы) и что результат должен существовать до тех пор, пока как минимум последний фьючерс на него ссылается, какой из потенциально многих фьючерсов, соответствующих вызываемой функции, должен содержать ее результат?

Поскольку ни объекты, связанные с вызываемой функцией, ни объекты, связанные с вызывающей функцией, не являются подходящими местами для хранения результата вызываемой функции, они должны храниться где-то вне этих объектов. Такое местоположение известно как общее состояние (shared state). Это общее состояние обычно представлено объектом в динамической памяти, но его тип, интерфейс и реализация в стандарте языка не указаны. Авторы стандартной библиотеки могут реализовывать общие состояния так, как хотят.

Мы можем представить себе отношения между вызываемой функцией, вызывающей функцией и общим состоянием следующим образом (пунктирными стрелками вновь представлен поток информации):

Существование общего состояния имеет важное значение, потому что поведение деструктора фьючерса — тема этого раздела — определяется общим состоянием, связанным с этим фьючерсом. В частности, справедливо следующее.

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

• Деструкторы всех прочих фьючерсов просто уничтожают объект фьючерса. Для асинхронно выполняющихся задач это сродни неявному отключению базового потока с помощью вызова detach. Для отложенных задач, для которых данный фьючерс является последним, это означает, что отложенная задача никогда не будет выполнена.

Эти правила выглядят сложнее, чем есть на самом деле. Мы имеем дело с простым “нормальным” поведением и одним исключением. Нормальное поведение заключается в том, что деструктор фьючерса уничтожает объект фьючерса. Вот и все. Он ничего не подключает, ничего не отключает, он ничего не запускает. Он просто уничтожает члены-данные фьючерса. (Ну, на самом деле он делает еще одно дело — уменьшает значение счетчика ссылок общего состояния, которое управляется как ссылающимися на него фьючерсами, так и объектами std::promiseвызываемой функции. Этот счетчик ссылок позволяет библиотеке знать, когда можно уничтожать общее состояние. Информацию по счетчикам ссылок вы можете найти в разделе 4.2.)

Исключение из этого нормального поведения осуществляется только для фьючерса, для которого выполняются все перечисленные далее условия.

• Он ссылается на общее состояние, созданное вызовом std::async.

• Стратегия запуска задачи — std::launch::async(см. раздел 7.2), либо потому, что она выбрана системой времени выполнения, либо потому, что была явно указана в вызове std::async.

• Фьючерс является последним фьючерсом, ссылающимся на общее состояние. Это всегда справедливо для std::future. Для std::shared_future, если при уничтожении фьючерса на то же самое общее состояние ссылаются другие std::shared_future, поведение уничтожаемого фьючерса — нормальное (т.e. просто уничтожаются его члены-данные).

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