On Wed, Oct 24, 2012 at 7:35 AM, Andrzej Krzemienski <akrzemi1@gmail.com> wrote:
2012/10/14 Andrzej Krzemienski <akrzemi1@gmail.com>
I guess you are referring to the case the std::future is created by async Or perhaps future destructor IS the last function that release the shared state. When we call async() two threads are involved: our 'master' thread and a newly launched thread. Whatever function(s) releases the shared state it has to do it from one of the two threads. The last release cannot be made from the 'launched' thread because 'launched' thread completion synchronizes with the last release. So the last release has to be performed from the 'master' thread. And what other operation in the 'master' thread apart from future's destructor can release the state?
I don't know the details, but it was clear from the discussions at the standard's meeting, that std::future blocks in its destructor - when originating from std::async(). But not in other cases. Which is completely inconsistent, and makes it hard to have a function that accepts a std::future - you no longer know where it came from and whether it blocked. I have started to read the minutes of the C++ standard committee but I don't reach to find out reasons. I would appreciate if someone could
The committee would really like to resolve that issue. Either always block, or never block. Possibly deprecating std::async() and replacing it with something that returns a non-blocking future. Or some other solution. async was a compromise as there wasn't enough time to complete a
As for whether users should use std::thread or something higher level - I think something higher. But not just a wrapper - a different mechanism. I think users should be encouraged to use an "executor". ie a thread-pool where you give it std::function object that it runs on other threads. Like std::async() but with more control of the threading, yet avoiding actual thread management. I agree end users are waiting for more high level interfaces. But I
Le 24/10/12 19:47, Gottlob Frege a écrit : point me to the details of the problem. thread_pool proposal. I didn't understood never why they didn't let the launch policy a template parameter. I would like to understand hwat is the bug on the async/future standard. Anthony, maybe you can clarify it. think some wrappers could make easier the work for high library writers. Note that I'm not proposing them for C++1y standardization, but to possible tools a Boost author can use.
Also very similar to Apple's Grand Central Dispatch.
I know a number of Adobe apps switched completely from using threads to using executors.
An executor has been proposed for C++1y. Maybe someone should add one to boost?
I stated some years ago Boost.Async (sandbox) that is based on the concept of asynchronous executors and asynchronous completion tokens. Given the interest that there in now for executors I should resurrect the project ;-) Best, Vicente