Boost logo

Boost :

Subject: Re: [boost] Futures
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2015-01-07 13:56:58


Le 06/01/15 20:22, Vicente J. Botet Escriba a écrit :
> Le 06/01/15 11:23, Niall Douglas a écrit :
>> On 5 Jan 2015 at 22:41, Vicente J. Botet Escriba wrote:
>>
>>>> For example, right now can boost::wait_all() ever consume
>>>> std::futures? I suspect not because the HANDLE on Windows or the
>>>> futex on Linux is rather hard to get at.
>>> The current implementation doesn't accept std::futures, but there is no
>>> reason it can not accept other futures. All what is needed is the
>>> Future::wait() interface.
>>>
>>> wait_for_any is different. The Boost thread implementation uses a list
>>> of condition_variable to notify when a the future becomes ready. Having
>>> a generic future<T>::notify_when_ready(condition_variable) will
>>> surely help.
>> I would *far* prefer a notify_when_ready(callable), not least because
>> condition_variables are lost wakeup prone.
> It is much easier to store a condition_variable than a Callable. In
> addition it ensures that the future value provider will not block
> until the callback finish and makes the user code thread safe, as the
> code is executed on the thread of its choice.
>> But then you're effectively making futures into ASIO async_result.
>>
>>
> I'm not a fan of async_result, as the way the function is used depends
> on a specific parameter. IMO, we need different functions when the
> user must follows a different protocol.
>

After some more thoughts, the callable interface is more open.

The condition_variable interface could be something like

// Return an unlocked LockableFutureHandle able to tell if the Future is
ready once the lock has been locked.
LockableFutureHandle Future::notify_when_ready(condition_variable&);

// pre-condition this is not locked
void LockableFutureHandle::lock();

// pre-condition this is locked
void LockableFutureHandle::unlock();

// pre-condition this is locked
void LockableFutureHandle::is_ready();

This seems a little bit intrusive and is needed as the user need to
check which future is ready.

Using a Callable (void()) like e.g.

template <class Callable>
voidFuture::when_ready(Callable&&);

that doesn't consume the future, the user is able to store on the
callable closure the mutex, the condition_variable and the index. When
called it can store the index as the one that is ready and notify the
condition variable.

An alternative could be to have some kind of lockable condition variable
wrapping an index. The wait function could return the index.

voidFuture::notify_when_ready(LockableConditionVariable<std::size_t>&);

The user would call it as follows

   LockableConditionVariable<std::size_t> lcvi(i);
   f.notify_when_ready(lcvi);

and will later call to wait to get the index.

   std::size_t index = lcvi.wait();

Best,
Vicente


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