T2. Join();

std:: cout < < res1 < < ' ' < < res2 < < '\n';

}

А как насчет ошибок? Что если задача генерирует исключение? Если задача генерирует исключение, и оно не обрабатывается в блоке catch, то вызывается метод std:: terminate(). А это обычно означает закрытие приложения, чего обычно мы очень сильно хотим избежать. std:: future может передать исключение в родительский/вызывающий поток; это одна из причин, почему мне нравится эта возможность. В противном случае, можно вернуть некоторый код ошибки.

Когда thread покидает область видимости приложение завершается вызовом метода std:: terminate(), если текущая задача еще не завершена. Очевидно, этого следует избегать.

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

· Разработать собственный механизм кооперативный отмены исполнения (с помощью разделяемых данных, вызывающий поток может установить значение, которое будет прочитано вызываемым потоком для быстрого и безопасного завершения),

· С помощью «нативного подхода» (получив доступ к дескриптору операционной системы с помощью thread:: native_handle()),

· Завершить процесс (с помощью std:: quick_exit()),

· Завершить программу (с помощью std:: terminate()).

Это все, о чем смогли договориться члены комитета. В частности, представители POSIX были ярыми противниками любой формы «отмены исполнения», хотя многие модели ресурсов в С++ основаны на деструкторах. Не существует идеального решения для любой системы и для всех возможных приложений.

Главная проблема при использовании потоков заключается в гонках (data races); т.е. два потока исполняются в одном адресном пространстве и могут независимо обращаться к объекту таким образом, что это приведет к непредвиденным результатам. Если один (или оба) потока будут изменять данные объекта и другой (или оба) потока будут читать данные объекта, то произойдет «гонка» за то, какая из операций будет выполнена первой. Результаты могут быть не просто неопределены; они обычно совершенно непредсказуемы. Во избежание гонок С++11 предоставляет программисту некоторые правила/гарантии:

· Функции стандартной библиотеки не должны прямо или косвенно обращаться к объектам, доступным из других потоков, если только эти объекты прямо или косвенно не передаются через аргументы функций (включая this).

· Функции стандартной библиотеки не должны прямо или косвенно изменять объекты, доступные из других потоков, если только эти объекты прямо или косвенно не передаются через аргументы функции (включая this).

· Реализации стандартной библиотеки должны избегать гонок за разные элементы в одной последовательности, которые могут изменяться параллельно.

Параллельный доступ к потоку ввода-вывода (stream) объектов, буферизированному потоку объектов или потоку из стандартной библиотеки С может привести к гонкам, если не указано обратное. Так, не следует разделять доступ к потокам ввода-вывода между двумя потоками исполнения, пока вы каким-либо образом не контролируете к ним доступ.

Вы можете:

· Ждать поток указанное время.

· Контролировать доступ к данным с помощью взаимного исключения (mutual exclusion).

· Контролировать доступ к данным с помощью блокировок.

· Ожидать действия другой задачи с помощью условных переменных.

· Возвращать значение из потока с помощью future.

См. также:

• Standard: 30 Thread support library [thread]
• 17.6.4.7 Data race avoidance [res.on.data.races]
• ???
• H. Hinnant, L. Crowl, B. Dawes, A. Williams, J. Garland, et al.: Multi-threading Library for Standard C++ (Revision 1) N2497==08-0007
• H.-J. Boehm, L. Crowl: C++ object lifetime interactions with the threads API N2880==09-0070.
• L. Crowl, P. Plauger, N. Stoughton: Thread Unsafe Standard Functions N2864==09-0054.
• WG14: Thread Cancellation N2455=070325.