main thread waits for std::async to complete [duplicate]

Question

I am using std::async to create a thread, I want this new thread should execute separately and main thread should not wait for it. But here when I call std::async, a new thread is created but main thread is waiting for completion of fun(). I want main thread to execute parallely without waiting for fun() to complete. How should I do that?

#include <iostream>
#include <windows.h>
#include <future>
using namespace std;



void printid()
{
   cout << "Thread id is:" << this_thread::get_id() << endl;
}

void fun(void *obj)
{

   cout<<"Entry"<<endl;
   printid();
   Sleep(10000);
   cout<<"Exit"<<endl;
}


int main()
{
    cout<<"Hello"<<endl;
    printid();
    std::async(std::launch::async, fun, nullptr);
    cout << "After call" << endl;
}

I am getting output:

Hello
Thread id is:22832
Entry
Thread id is:13156
Exit
After call

Answer 1

A std::future object returned by std::async and launched with std::launch::async policy, blocks on destruction until the task that was launched has completed.

Since you do not store the returned std::future in a variable, it is destroyed at the end of the statement with std::async and as such, main cannot continue until the task is done.

If you store the std::future object, its lifetime will be extended to the end of main and you get the behavior you want.

int main()
{
    ...
    auto fut = std::async(std::launch::async, fun, nullptr);
    ...
}

Answer 2

std::async(std::launch::async, fun, nullptr);

Doesn't do anything with the returned std::future, leaving it to be destroyed. That's a problem because std::future's destructor may block and wait for the thread to finish.

The solution is to hold on to the std::future for a while and let it be destroyed after you're done with everything else.

auto locallyScopedVariable = std::async(std::launch::async, fun, nullptr);

locallyScopedVariable will go out of scope at the end of main and then block until it completes.

Note that this still might not do quite what you want. The main thread could immediately yield the processor to the new thread and allow the new thread to run to completion before control is returned. The code can be corrected and still result in the output of the incorrect version.