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