Re: [boost] [future N2561] Implementation comments

Subject: Re: [boost] [future N2561] Implementation comments
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-12-03 07:29:20

----- Original Message ----- 
From: "Anthony Williams" <anthony.ajw_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, December 03, 2008 11:17 AM
Subject: Re: [boost] [future N2561] Implementation comments

> 
> "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().

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