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.

Answer 2

I've looked at the documentation of std::future and found this for the destructor of std::future:

Releases any shared state. This means

• if the return object or provider holds the last reference to its shared state, the shared state is destroyed; and
• the return object or provider gives up its reference to its shared state; and
• these actions will not block for the shared state to become ready, except that it may block if all of the following are true: the shared state was created by a call to std::async, the shared state is not yet ready, and this was the last reference to the shared state.

Pay attention on the last point. In my opinion you have to call the get's at the end of your scope.