Re: [boost] [future] Is a super-lightweight future possible?

From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2008-05-16 09:56:49

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 16 May 2008 04:54 am, John Maddock wrote:
> With apologies for coming to the discussion late, it seems to me that many
> future implementations including the ones under discussion are high level
> interfaces that are "feature rich".  Nothing wrong with that, it's exactly
> what a lot of folks need.
>
> But I would also be interested in a super-lightweight future used for more
> low-level task-based parrallelism.  In my dreams <g>, it would be something
> like:
>
> * Create a scoped object that executes the "future" in parrallel,
> constructing the object would be no more expensive than a trivial function
> call - so no memory allocation or mutexes allowed, only lock-free
> programming.
> * The future would be executed using a thread drawn from a pool - or
> possibly a local team - so there's no thread creation overhead either
> (except at program startup, or possibly the first time a future is
> invoked). * At a later point in the same scope, join with the future, again
> this should be a "trivial" lock-free operation if the future has completed.
>
> So... is such a beast possible?  Or are threads actually too heavyweight
> for such usage?

You seem to be describing something closer to an active object than a future.  
The primary responsibility of a future is not to execute code (although we 
have been discussing callbacks which would allow that).  Its main job is just 
to provide a handle which can be used to conveniently obtain a result that 
may not exist yet (and might be produced in a different thread) in a 
thread-safe way.

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

iD8DBQFILZKp5vihyNWuA4URAqBFAJ9Rh/YpLUgnJ7pbcLr8V+ggZdL59wCfXRGN
C7HMaengDIl/926aBTi0HLU=
=EUKU
-----END PGP SIGNATURE-----