Re: [boost] [future N2561] Implementation comments

Subject: Re: [boost] [future N2561] Implementation comments
From: Anthony Williams (anthony.ajw_at_[hidden])
Date: 2008-12-03 14:35:37

Anthony Williams <anthony.ajw_at_[hidden]> writes:

> "vicente.botet" <vicente.botet_at_[hidden]> writes:
>
>> on the current Future (N2561) library proposal the promise protect
>> the value setting/getting from multiple threads using a lock, but
>> the lock do not protect the future initialization (lazy_init()).
>>
>>         void set_value(typename detail::future_traits<R>::source_reference_type r)
>>         {
>>             lazy_init();
>>             boost::lock_guard<boost::mutex> lock(future->mutex);
>>             if(future->done)
>>             {
>>                 throw promise_already_satisfied();
>>             }
>>             future->mark_finished_with_result_internal(r);
>>         }
>>
>> I'm wondering if we don't need to extend the protection or avoid the
>> lazy initialization? I'm missing something?
>
> Concurrent calls to set_value are not supported with this
> implementation. The mutex is there to protect concurrent calls to
> unique_future::get() and promise::set_value().

Actually, thinking about it some more, and remembering the rationale,
I'll revise that statement.

Once a promise has an associated asynchronous value, it is safe to
call set_value concurrently from multiple threads, since lazy_init is
a no-op. If you call get_future() then this initialization is
forced. Alternatively, it is trivial to add a call to lazy_init to the
default constructor.

If, however, you move the promise into another promise then it no
longer has an associated asynchronous result, and must again be
initialized before concurrent calls to set_value are safe. You can do
this by moving a default-constructed promise into the promise in
question, or calling get_future on it.

It might be worth removing the lazy_init call from set_value and
get_future in order to make this clear --- if you move from a promise,
you have to move into it in order to use it again.

Anthony
-- 
Anthony Williams
Author of C++ Concurrency in Action | http://www.manning.com/williams
Custom Software Development | http://www.justsoftwaresolutions.co.uk
Just Software Solutions Ltd, Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK