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
yep.
(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 there?) Apologies in advance if I'm not getting something obvious... Matt