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