From: Matthew Vogt (mvogt_at_[hidden])
Date: 2004-02-16 22:04:06
scott <scottw <at> qbik.com> writes:
> > AO's should either have a queue for work or hook into a
> > queue. They are
> > a bit like a worker pool with one worker
(Aside: the Rhapsodia scheduler mentioned recently had an interesting
implementation of the worker pool, which could presumably be as simple
as a single thread serially processing scheduled tasks.)
> > 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.
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...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk