From: Peter Dimov (pdimov_at_[hidden])
Date: 2007-03-10 04:37:59
Jeff Garland wrote:
> Sure, but the point of the active object is that the concurrency
> approach is a detail is hidden behind the interface of the object.
It's clear that you're using a broader definition of "active object" - any
object that provides an asynchronous interface. I'm not, I'm interested in
the specific case of:
>> 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
The significance of the classic definition is that you can take an existing
single threaded object and turn it into an active object _automatically_. In
Concur, for example, the language can do that for you; the various proposals
for a Boost implementation do something similar.
If you use the broader definition, AO becomes a pattern, and you can't
implement it in either the language or the library.
> If you haven't already you might want to have a look at this paper:
I will, thank you.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk