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. :-)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk