On Fri, Sep 4, 2015 at 11:56 PM, Vicente J. Botet Escriba
wrote:
Hi Giovanni,
boost::future has a lot of design issues. I will welcome and base class from
which boost::future can inherit as it is quite difficult to maintain it by
myself :(. I'm a little bit skeptical about the approach, but who knows.
what are your concerns in particular?
Basically what I would like is to decouple the signalling of a future
shared_state, as done by e.g. the promise, from the action to be
taken. The intuition is that most efficient implementations of
synchronization primitives are based on a fast lock free user space
signalling path plus a slow kernel path in case there are waiters. My
idea is to decouple the slow path from the actual signalling
implementation. The decoupling is done via an interface like this:
struct signalable {
virtual void signal() = 0;
atomic next = 0;
};
An actual signalable implementation could invoke a continuation
(unifying then and wait), signalling a condition variable, an event, a
file descriptor, switching to another fiber etc.
The signaler side has something like this:
struct signaler {
void signal();
bool try_wait(signalable *);
bool try_unwait(signalable*);
};
Note this is not virtual. In fact it could simply be a concept.
Try_wait attempts to add the signalable to the wait list for the
signaler. Failure means that the signaler was signaled in the
meantime. try_unwait attempts to remove the signalable from the wait
list. Failure also means that the signaler was signaled in the
meantime.
The signaler can be implemented lock_free except in the case in which
try_unwait is called *and* there are multiple waiters. I believe this
case can be handled with a spinlock just for mutual exclusion between
unsignalers (try_waiters and signal can still be lock free), but I
have yet to implement it
With this interface a future can be implemented without any additional
synchronization.
For example the default implementation of 'then' would simply allocate
a new shared state for the returned future which inherit from
signalable and register it to the shared_state of the previous
continuation. The callback is allocated inline in the shared_state.
When signal is called, the callback is invoked.
The default wait of course would create a wait object on the stack (or
have a thread local one) which also implements the signalable
interface (a portable implementation would be based on a condition
variable + boolean flat + mutex). A timed wait need to use the
try_unwait interface if the clock times out.
Sorry for the rambling, hopefully the idea is a bit clearer.
I have shared my implementation previously. This is the link again:
https://github.com/gpderetta/libtask/blob/master/future.hpp
Note: incomplete, buggy and definitely not production ready.
Note that boost::future and boost::thread have some interactions (at thead
exit family functions) that need to be taken in account
I imagine that can be tricky. Is it much more complex than the thread
holding a pointer to the shared state to be made ready on exit?
-- gpd
