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