Boost logo

Boost :

Subject: Re: [boost] [thread] terminating destructor
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-10-24 15:47:30

Le 24/10/12 19:47, Gottlob Frege a écrit :
> On Wed, Oct 24, 2012 at 7:35 AM, Andrzej Krzemienski <akrzemi1_at_[hidden]> wrote:
>> 2012/10/14 Andrzej Krzemienski <akrzemi1_at_[hidden]>
>>>>> 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
point me to the details of the problem.
> 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
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.
> 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
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 ;-)


Boost list run by bdawes at, gregod at, cpdaniel at, john at