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

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.

yeah baby.

with some talk of the overheads its nice to touch on some
benefits. simplicity of client and simplicity of servant (or
active object).

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
work :-)

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
is.

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
> there?)
> 
> 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.

cheers,
scott