"vicente.botet" <vicente.botet@wanadoo.fr> 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(). Protection of lazy_init would require a different mechanism, such as the use of boost::call_once.
BTW, Is it safe to take the address of a promise? If not, why not delete the operator&()?
Yes, it's safe. If someone move-assigns it you might not be associated with the same result you thought you were, but it's safe. 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