Boost logo

Boost :

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

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.

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


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