This is the mail archive of the
mailing list for the libstdc++ project.
Re: [C++0x] a better <future>
- From: Benjamin Kosnik <bkoz at redhat dot com>
- To: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- Cc: "libstdc++" <libstdc++ at gcc dot gnu dot org>
- Date: Wed, 17 Jun 2009 19:11:22 -0700
- Subject: Re: [C++0x] a better <future>
- References: <email@example.com>
> Any memory required for the result is allocated in the promise
> constructor, fixing a weakness in my previous design. This also makes
> it easier to add allocator support later.
> The result is initialized via placement new so the stored value
> doesn't need to be default constructible or assignable, only move
> constructible. Initialization isn't inside a critical section,
> preventing a deadlock in the 30_threads/promise/members/set_value3.cc
> Extending promise and packaged_task to use allocators will be
> relatively simple, it could be done now if the allocator_arg_t tag
> type existed. The virtual Future_result_base::_M_destroy() function
> exists so that it can be overridden by derived types using alternative
> allocators. I hope that will avoid an ABI change when allocator
> support is added.
This is one of the things we need to remember to look out for in the
gcc-4.5 release process, when we'll (hopefully) know more about the
allocator issues. Can you please add a note or XXX ABI comment to the
base member function _M_destroy so that this is a bit more obvious?
> This version started out using a std::atomic_address to hold the
> result, avoiding a mutex lock when setting the result or polling the
> state, but the performance was much better with mutex locks. The
> version of Future_state using atomics has the same interface, so could
> be changed later if performance of the atomics improves.
FYI please put the tests you are using to make these kinds of decisions
into testsuite/peformance. Assuming you were testing on linux?
> I'm pretty happy with this version, but I'm open to suggestions for
While reading this, it seems as if -fno-exceptions will probably die on
it. I'm not quite sure if any of the C++0x stuff has been audited for
-fno-exceptions. This shouldn't stop this patch from going in.
This looks good to me, please put this in and thanks!