Re: [boost] [futures] boost::futures

From: Jeff Garland (jeff_at_[hidden])
Date: 2007-03-09 19:15:59

Peter Dimov wrote:
> Braddock Gaskill wrote:
> 
>> I noticed that none of the "future" C++ standardization proposals by
>> Hinnant and Dimov, as well as Sutter's Concur implicitly create a new
>> thread upon future construction like your simple_future
>> implementation.
>> As far as I can tell, their future classes are very simple and almost
>> completely agnostic to the scheduling, threading, etc particulars.
> 
> Indeed, the intent has been for futures to support arbitrary asynchronous 
> task execution, not just the simple thread per task model. One could imagine 
> using futures over an interprocess protocol or TCP/IP.
> 
> My current proposal for std::future<R> is available at
> 
> http://www.pdimov.com/cpp/N2185.html
> 
> and will be part of the pre-meeting mailing. We'll see how it fares.
> 
> As an aside, does anyone have a success story about active objects? I can't 
> seem to grasp their significance; in particular, how are they supposed to 
> scale to many cores/HW threads if every access is implicitly serialized? 

Sure, they're useful.  Couple ways they can scale.  You might have a large 
number of totally independent active objects running at any giving time.  For 
example, imagine and 'endpoint' handler for a telephone calls -- it's a 
complex state machine that's executes a bunch of commands as new events 
arrive.  If you handle lots of calls and you map 1 per thread then you are 
effectively scaling to many cores by having lots of active objects.  Probably 
a better design is to have a pool of threads wake up the AO when a new event 
arrives, b/c at any moment most of the objects are idle and there's no point 
in tying up a thread.

Totally different approach is for a single active object to have a pool of 
threads to dispatch execution of long running tasks within the AO.  In this 
design even though the start of tasks is serialized the end might not be.  The 
AO needs to be essentially stateless for this approach to work.

HTH,

Jeff