Аккумулировав результаты но последнему блоку, мы можем дождаться завершения всех запущенных потоков с помощью алгоритма std::for_each
(10), а затем сложить частичные результаты, обратившись к std::accumulate
(11).
Прежде чем расстаться с этим примером, полезно отметить, что в случае, когда оператор сложения, определенный в типе T
, не ассоциативен (например, если T
— это float
или double
), результаты, возвращаемые алгоритмами parallel_accumulate
и std::accumulate
, могут различаться из-за разбиения диапазона на блоки. Кроме того, к итераторам предъявляются более жесткие требования: они должны быть по меньшей мере однонаправленными , тогда как алгоритм std::accumulate
может работать и с однопроходными итераторами ввода . Наконец, тип T
должен допускать конструирование по умолчанию (удовлетворять требованиям концепции DefaultConstructible ), чтобы можно было создать вектор results
. Такого рода изменения требований довольно типичны для параллельных алгоритмов: но самой своей природе они отличаются от последовательных алгоритмов, и это приводит к определенным последствиям в части как результатов, так и требований. Более подробно параллельные алгоритмы рассматриваются в главе 8. Стоит также отметить, что из-за невозможности вернуть значение непосредственно из потока, мы должны передавать ссылку на соответствующий элемент вектора results
. Другой способ возврата значений из потоков, с помощью будущих результатов , рассматривается в главе 4.
В данном случае вся необходимая потоку информация передавалась в момент его запуска —в том числе и адрес, но которому необходимо сохранить результат вычисления. Так бывает не всегда; иногда требуется каким-то образом идентифицировать потоки во время работы. Конечно, можно было бы передать какой-то идентификатор, например значение i
в листинге 2.7, но если вызов функции, которой этот идентификатор нужен, находится несколькими уровнями стека глубже, и эта функция может вызываться из любого потока, то поступать так неудобно. Проектируя библиотеку С++ Thread Library, мы предвидели этот случай, поэтому снабдили каждый поток уникальным идентификатором.
2.5. Идентификация потоков
Идентификатор потока имеет тип std::thread::id
, и получить его можно двумя способами. Во-первых, идентификатор потока, связанного с объектом std::thread
, возвращает функция-член get_id()
этого объекта. Если с объектом std::thread
не связан никакой поток, то get_id()
возвращает сконструированный по умолчанию объект типа std::thread::id
, что следует интерпретировать как «не поток». Идентификатор текущего потока можно получить также, обратившись к функции std::this_thread::get_id()
, которая также определена в заголовке .
Объекты типа std::thread::id
можно без ограничений копировать и сравнивать, в противном случае они вряд ли могли бы играть роль идентификаторов. Если два объекта типа std::thread::id равны
, то либо они представляют один и тот же поток, либо оба содержат значение «не поток». Если же два таких объекта не равны, то либо они представляют разные потоки, либо один представляет поток, а другой содержит значение «не поток».
Библиотека Thread Library не ограничивается сравнением идентификаторов потоков на равенство, для объектов типа std::thread::id
определен полный спектр операторов сравнения, то есть на множестве идентификаторов потоков задан полный порядок. Это позволяет использовать их в качестве ключей ассоциативных контейнеров, сортировать и сравнивать любым интересующим программиста способом. Поскольку операторы сравнения определяют полную упорядоченность различных значений типа std::thread::id
, то их поведение интуитивно очевидно: если aи bто а<���с
и так далее. В стандартной библиотеке имеется также класс std::hash
, поэтому значения типа std::thread::id
можно использовать и в качестве ключей новых неупорядоченных ассоциативных контейнеров.
Объекты std::thread::id
часто применяются для того, чтобы проверить, должен ли поток выполнить некоторую операцию. Например, если потоки используются для разбиения задач, как в листинге 2.8, то начальный поток, который запускал все остальные, может вести себя несколько иначе, чем прочие. В таком случае этот поток мог бы сохранить значение std::this_thread::get_id()
перед тем, как запускать другие потоки, а затем в основной части алгоритма (общей для всех потоков) сравнить собственный идентификатор с сохраненным значением.
Читать дальше