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. 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. 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. 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? Tony