std::list<std::future> destructor does not block

Question

I have a multithreaded application, with an loop waiting for user input as main thread. On the correct input, it is supposed to stop the loop and wait for all other threads, to end propperly.

For this purpose I created an std::list in which I put the std::future objects created for thread creation

std::list<std::future<int>> threads;
threads.emplace_front(std::async(std::launch::async, ...));

I was under the impression, that letting the list run out of scope, should block, until all threads return their main function, because the lists destructor will destrurct all std::future elements and the destructor of those will wait, for the thread to finish.

EDIT: Since it is relevant I will add it here: This is on Win7 with the MSVC version in Visual Studio 2013 Professional /EDIT

When I tried this, it didn't block, I had to add

for (auto it = threads.begin(); it != threads.end(); ++it) {
    it->get();
}

to the end of the function, to block correctly.

Did I missunderstand something, or do I have to create the thread in a different way, to do what I want to do here?

Answer 1

This is a MSVC bug that has been fixed, but the fix won't be available until MS releases a new version of Visual C++, probably some time in 2015. (It's also available in the CTP for the new version, but it's a pretty bad idea to use that for any production code...)

As Scott Meyers explained in his blog post, the destructor of a std::future returned by a std::async call using the launch::async policy is required to block until the spawned thread completes execution (§30.6.8 [futures.async]/p5):

If the implementation chooses the launch::async policy,

• [...]
• the associated thread completion synchronizes with (1.10) the return from the first function that successfully detects the ready status of the shared state or with the return from the last function that releases the shared state, whichever happens first.

In this case, the future's destructor is the "last function that releases the shared state", so the thread completion must synchronize with (i.e., happen before) the return of that function.