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

From: Jeff Garland (jeff_at_[hidden])
Date: 2007-03-09 20:06:03

Peter Dimov wrote:

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

Well, for sake of discussion, lets say it represents the 'call' between one or 
more telephones.  So when someone starts to place a call a new active 
object/thread is created on a server to process the call.  Depending on the 
kind of phone system it will do stuff like collect digits, execute timeouts, 
see of the other end is available, keep track of billing, setup network 
connections, handle disconnects from phones, etc.  Each method on the object 
is inherently asynchronous and often depends on getting information from a 
remote servers.  This kind of object obviously would live in a larger 
distributed system, but at the server level the strategy is to code the 'call 
object' as an active object that responds to events.  In the real world it 
might be a tad more complicated -- like you might have active objects for 
devices as well -- but hopefully that explains the basic idea.

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

Sure, but the point of the active object is that the concurrency approach is a 
detail is hidden behind the interface of the object.

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

Ok, I was a bit sloppy...the object can have state, it's just that the methods 
that are spawned to execute in a thread pool must be independent of any state 
changes the other makes.  In the case of the 'call object' the order things 
arrive impacts the results.  Some other kinds of objects (eg: the call object) 
that isn't true.

If you haven't already you might want to have a look at this paper:

http://citeseer.ist.psu.edu/lavender96active.html

Jeff