From: scott (scottw_at_[hidden])
Date: 2004-02-16 23:37:57
> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]]On Behalf Of Matthew Vogt
> > > Another idiom is a future value, where you ask for a
> value and don't
> > > block until you "read" the value. ACE also has an
> implementation of
> > > this. You can think of it as a bit like overlapped I/O.
> > Yes. This was also in the ActiveObject pattern. It was on
> the "client-
> > side", i.e. available to the thread that submits Method
> Requests as a
> > means to acquire the results.
> > While I understand its place in the ActiveObject pattern I
> would hope
> > that if a boost::active_object came into existence, there would be a
> > single (i.e. not _simple_) mechanism by which data passed
> from one thread
> > to the other, with an associated notification. In a
> behavioural sense,
> > the future mechanism wouldnt be appropriate for this.
> To my way of thinking, the advantage of the active object is
> that all its
> methods are processed in a single thread, preventing
> concurrent access to
> any of its resources. Unless there is only a single
> resource, then the
> active object denies opportunities for overlapping
> concurrency that would
> be inherent through the use of other designs. The upside I
> can see is
> the simplicity for the client, in that they needn't be aware
> of any issues
> relating to concurrency.
with some talk of the overheads its nice to touch on some
benefits. simplicity of client and simplicity of servant (or
i have accidentally implemented something very similar to
the ActiveObject pattern. recently i have had to apply that
implementation within a codebase involving millions of lines
of code - and it worked!
there were expected benefits along the lines of what
you mention but there were some pretty wild ones as
well. cant really give a full explanation without
consideration of my employer but heres a summary.
without an active object approach, development has to
deal with the "normal" issues anyhow, e.g. encapsulation/OO
and concurrency. code actually "grows" according to
certain rules that cant be ignored by anyone (or it dont
imposing the active object model "over the top" of
this type of code went well because the model is a
model of what we do! thats sounds too cute but there it
a class had been written that needed to be a thread - so
it was. it had its own message queue and mechansims for
submitting work. there was a second class that was a
proper encapsulation of significant function - it deserved
to be a separate class. it was only ever accessed by
the first class.
after "activating" this code, the previous interfaces (pre-existing
message queue and sync methods) were left entirely alone. but
with the new (completely distinct) message queue, we could
exchange messages with the first class (instance, of course)
_and_ with the second (cos it was a uniquely identified servant
owned by the first class). this was a pleasant surprise.
dont know that this case study reads very well so i'll go out
on a limb - first class was a DNS server and the second was
a DNS cache.
> Of course, an active object could internally contain any
> number of threads,
> provided that correct internal synchronisation was maintained.
> Allowing the use of asynchronous I/O seems to break the
> abstraction, which
> leaves me wondering why the object should be active? (This
> is in the context
> of *local* objects, BTW - if the object is remote there is
> very little
> difference between a client/server solution and one using
> active objects, is
> Apologies in advance if I'm not getting something obvious...
all bang on, as far as i can tell anyhow :-) we're all
swimming up the same creek i think.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk