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
else.
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.
Johan
-- View this message in context: http://www.nabble.com/future-.vs.-Join%2C-is-%22future%22-a-form-of-message-passing--tp17269380p17270588.html Sent from the Boost - Dev mailing list archive at Nabble.com.