Re: [boost] [future N2561] Implementation comments

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

"vicente.botet" <vicente.botet_at_[hidden]> 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