Boost logo

Boost :

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


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

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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk