----- Original Message ----- From: "Anthony Williams" <anthony.ajw@gmail.com> To: <boost@lists.boost.org> Sent: Wednesday, December 03, 2008 11:17 AM Subject: Re: [boost] [future N2561] Implementation comments
"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().
Ok, I see. Do we need to set_value from different threads? Should the promise::set_value() be thread safe or not? What says the C++0x standard?
Protection of lazy_init would require a different mechanism, such as the use of boost::call_once.
Why not?
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.
I was not talking of move-assigning but to take the address which preserve the promise contents and is dangerous if concurrent calls to set_value are not supported with this implementation. So, why not delete the operator&()? Vicente