I updated my Visual Studio from 2013 to 2017. Compiling was fine but it seems like that the std::async call didn't open a new thread. (I cant see a new one in the thread-window while debugging. Also it looks like the thread which calls the the async function does the job...)
That is my function call:
std::async(std::launch::async, myfunction, this);
I didn't change anything in my code and in VS2013 was everything working fine.
Any Idea? Google can't tell me a lot about this but maybe i have the wrong keywords. So keywords would also help!
Thank you
Looks like std::async is whaiting for return to end. So, if you symply call it, doesn't work asynchronous.
The Key is define an answer: myfunction must to return std::future and you need to define and same type to response.
In case you call std::async inside a constructor, foo must be member of the class.
And, when you call std::async must be
In VS2013,
std::async
does not obey the C++ standard.There was a disagreement, and the developers working on MSVC wanted
std::async
'sstd::future
to behave like every otherstd::future
.The standard disagreed.
They released a non-standard compliant
std::future
in 2013. In 2015 if I remember correctly, they started following the standard.The standard states that the destructor of the
std::future
owning the shared state generated bystd::async( std::launch::async
blocks until the task is complete.This is because, in practice, dangling threads are bad for programs behaving in a predictable manner.
You are now in charge of owning and persisting the
future
returned fromand
f.wait
orf.get
ing it when you need it to be ready.This may require changing how your code works; for example, keeping a vector of futures around (if you have more than one), or adding a
std::future<?>
member tothis
and storing it (this also ensures that the async call doesn't outlive the object lifetime!).As a second note,
std::async
on windows also uses a bounded thread pool; if there are more than a certain number ofasync
tasks active, new tasks may not be launched.They have plans to fix it (as it goes against the advice in the standard), but at this point I would still recommend using
std::thread
, and if you needstd::async
like behavior implementing something similar yourself.My personal tendency is to create problem-specific
thread_pool
s that own a certain number ofstd::thread
s, but let you queue tasks and getfuture
s (with custom extensions that give me very limited continuation capabilities) back from it.This makes the thread ownership and dependencies more explicit, and avoids dealing with the MSVC non-standard compliant quirks that still exist.
You need to hold on to the
std::future
returned byasync
otherwise the destructor of the temporary will block until the work is finished.Very simple Solution: