Boost logo

Boost :

From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2008-06-02 16:59:42

Hash: SHA1

On Monday 02 June 2008 15:58 pm, Peter Dimov wrote:
> I think that wait_for_any would be enough for such a scheduler. In
> pseudocode, the dependency-resolving thread

I didn't mention it, but I was thinking of a scheduler picking method requests
and dispatching them using a single thread. At one extreme, you could create
a thread that returns a future and then blocks on wait_for_any/wait_for_all
in order to implement something that acts like future_select or
future_combining_barrier, but it's less than ideal.

> would do something like the
> following, in a loop:
> set< future<void> > waiting_, ready_;
> wait_for_any( waiting_ );

A scheduler which takes O(N) to dispatch a method request is considered
inefficient. N being the number of pending method requests in the scheduler.
The call to wait_for_any alone is O(N), thus my motivation for using
future_selector for a scheduler. I'll let you in on a dirty secret: the
scheduler I'm using now is O(N), but I'd hate not to be able to improve it to
something respectable when I need to.

> // for_each in waiting_
> // if ready() move to ready_
> // for each pending target
> // if dependencies are a subset of ready_, move to exec queue
> // garbage-collect ready_ in some way :-)

Version: GnuPG v1.4.6 (GNU/Linux)


Boost list run by bdawes at, gregod at, cpdaniel at, john at