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

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.