Boost logo

Boost :

Subject: Re: [boost] [thread] terminating destructor
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2012-10-24 13:47:40


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.

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk