Boost logo

Boost :

From: Johan Torp (johan.torp_at_[hidden])
Date: 2008-05-16 05:12:10

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.

My hope is that we can standardize some basic future in step 1 and lots of
libraries/features building on it in step 2.

I have also been concerned that future is not as light weight as I'd hope'd
it be.

John Maddock wrote:
> 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.

You seem to be thinking of the future as unfinished work. It might also be a
pending response to an out-of-process asynchronous request or something

John Maddock wrote:
> So... is such a beast possible? Or are threads actually too heavyweight
> for
> such usage?

I don't know. I haven't been think about lock-less programming at all, but I
will keep it in mind.


View this message in context:
Sent from the Boost - Dev mailing list archive at

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