Re: [boost] Re: Future of threads (III)

From: Jeff Garland (jeff_at_[hidden])
Date: 2004-02-17 08:19:41

On Tue, 17 Feb 2004 01:51:17 +0000 (UTC), Matthew Vogt wrote

> Do you know what classes of apps use the active object pattern?  The 
> example in the Douglas Schmidt paper doesn't really provide much 
> explanation for why you might want active local objects.

Sure, there are lots of cases where I can imagine the active object being a
nice abstraction.  I believe the key uses are where there is distributed
object state and timing/hardware resources that need to be handled. For
example, imagine that we are creating a server that manages call processing
for telephones.  We would have a few active objects here -- device objects to
represent the phones and 'call state' objects to represent the connection
between the phones.  The device objects need to synchronize their access to
hardware resources, including periodic polling of device state (off hook,
on-hook, etc).  So it makes lots of sense for a single thread of execution to
manage this hardware device.  There is also a need for other objects to change
the state of the phone device object by sending it messages or commands (eg:
connect to tone, hang up, etc). The 'call state' object is an independent
thread of execution as it needs to manage timing issues (eg: after 10 seconds
give nasty tone to caller since they only dialed three digits and stopped) as
well as interact with the devices involved in the call.  The 'call state'
object would be created when a phone begins the process of making a call and
persist until that call is complete.  I've worked on these kinds of systems,
but it was mostly before objects had become practical to use....

This is in contrast to something like a 'Market Data Server' which would take
a data feed of trading data from a stock exchange, update a database, do some
data transformation, and distribute information to clients.  In this case
there is no hardware state to maintain.  And yeah, we might want another
thread to put stuff in the database so the server doesn't block waiting for
the database but Active Objects just don't really add much here.

As for whether active objects are local or distributed across several
processes in the example I gave they would typically be distributed, but they
wouldn't have to be.  The key is that the practical issues of managing the
resource accesses and timing make the AO a nice match for the actual problem.

Finally, in the POSA2 book Schmidt et. al
(http://www.cs.wustl.edu/~schmidt/POSA/) cite an automatic call router and an
imaging system application as the example apps.

Jeff