Boost logo

Boost :

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


-----BEGIN PGP SIGNED MESSAGE-----
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 :-)
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIRF8+5vihyNWuA4URAj9LAJ4lsjOLJp0MvElF+rrgAg2DXl35UQCgoJH/
1RUsOThKBrKVFjBJL026jUM=
=fgK/
-----END PGP SIGNATURE-----


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