Re: [boost] Updated version of futures library

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-----