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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2007-03-09 19:31:38

Jeff Garland wrote:
> Peter Dimov wrote:

>> 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.

I figured that many active objects would be able to scale, I just wasn't 
able to come up with a realistic use case.

> 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.

I'm afraid that I still don't get it. What does an active object represent 
in this scheme, and who is invoking its methods and waiting for its results?

[...]

> 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.

A stateless object is not an interesting case since it's essentially a bunch 
of functions inside a namespace. One could simply use future+fork to spawn 
the calls. The classic active object idiom, as I understand it, deals with 
the shared state problem by implicitly serializing the method calls via a 
message queue, so that concurrent access to the state is eliminated. It's 
possible that the term has grown since then. :-)