Re: [C++0x] a better <future>

[Jonathan Wakely <jwakely dot gcc at gmail dot com>]

2009/6/18 Benjamin Kosnik:
>
>> 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?

Will do.  My intention is to have a Future_result_with_alloc<Result,
Alloc> derived from Future_result<Result>, and storing an allocator
instance.  The Future_state will only hold a pointer to
Future_result<Result> so the allocator disappears via type-erasure,
but will be used to deallocate by the virtual
Future_result_with_alloc::_M_destroy.

>> 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.
>
> OK.
>
> FYI please put the tests you are using to make these kinds of decisions
> into testsuite/peformance. Assuming you were testing on linux?

Yes, I will do some performance comparisons on some other arch's using
the gcc compile farm, but the performance difference on linux was
significant (2.5 times slower) so I gave up on the atomic version.  I
assume the reason is that linux mutexes and condvars are already very
well-tuned whereas the <cstdatomic> code is less mature.
The performance test was quite artificial: several threads constantly
polling a future for readiness to intentionally create contention,
then one thread setting the value, but I'll tidy it up for inclusion.
Testing any other parts of the interface would only test the
performance of waiting on a condvar, copying the result, or throwing
exceptions, so I only tested the performance of is_ready() and
set_value().

>> I'm pretty happy with this version, but I'm open to suggestions for
>> improvements.
>
> 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.

Ah yes, I thought of that, then forgot about it!

std::function / tr1::function do this:

#if __EXCEPTIONS
          throw bad_function_call();
#else
          __builtin_abort();
#endif

and similarly for bad_weak_ptr, so I could do the same, but we should
consider adding the C++0x.exceptions to bits/functexcept.h -

> This looks good to me, please put this in and thanks!

OK, I'll add the comment and performance test asap and check in. Thanks,

Jonathan