"vicente.botet" <vicente.botet@wanadoo.fr> writes:
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?
The C++0x draft standard is silent on the matter. I think it probably
Protection of lazy_init would require a different mechanism, such as the use of boost::call_once.
Why not?
The existing lock uses future->mutex. Until lazy_init is called for the first time, future is a NULL pointer, so we can't use future->mutex. You could use a second mutex to protect the future pointer, but it would be unnecessary locking after the first call (or the first call after a move).
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&()?
Just because something is not thread safe does not make it appropriate to delete the operator&. You can pass things around by pointer without making them accessible to more than one thread, and you can pass things by reference that ARE accessible by more than one thread, even if that isn't 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