threads - thread linux c++

el comportamiento de std:: async con std:: launch:: async policy

Question

Tengo algunas preguntas sobre el comportamiento de la función std::async con std::launch::async policy & std::future objeto devuelto desde async.

En el siguiente código, el hilo principal espera la finalización de foo() en el hilo creado por una llamada async .

#include <thread>
#include <future>
#include <iostream>
void foo()
{
std::cout << "foo:begin" << std::endl;
std::this_thread::sleep_for(std::chrono::seconds(10));
std::cout << "foo:done" << std::endl;
}
int main()
{
std::cout << "main:begin" << std::endl;
{
auto f = std::async(std::launch::async, foo);
// dtor f::~f blocks until completion of foo()... why??
}
std::this_thread::sleep_for(std::chrono::seconds(2));
std::cout << "main:done" << std::endl;
}

Y sé que http://www.stdthread.co.uk/doc/headers/future/async.html dice

El destructor del último objeto futuro asociado con el estado asíncrono del std :: future devuelto se bloqueará hasta que el futuro esté listo.

Mi pregunta es:

• Q1. ¿Este comportamiento se ajusta al estándar actual de C ++?
• Q2. Si la respuesta de Q1 es sí, ¿qué afirmaciones dicen eso?

Answer 1

Sí, esto es requerido por el estándar de C ++. 30.6.8 [futures.async] párrafo 5, punto final:

- la terminación de la hebra asociada sincroniza con (1.10) el retorno de la primera función que detecta con éxito el estado listo del estado compartido o con el retorno de la última función que libera el estado compartido, lo que ocurra primero.

El destructor del único e std:future satisface esa condición, por lo que debe esperar a que se complete el subproceso.