[boost] Re: Future of threads (III)

From: Matthew Vogt (mvogt_at_[hidden])
Date: 2004-02-17 00:22:00

Hurd, Matthew <hurdm <at> sig.com> writes:

> 
> > On Behalf Of Matthew Vogt
> > 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
> > 
> 
> I think you're confusing the reference to asynch i/o I made, or I'm
> confused.  Recent form would suggest the latter 
> 

Ah, now I see my confusion. (But it's not about synch I/O, I followed
you allusion ok.) The start of a form reversal for you, perhaps?

> I was suggesting that a future value is a bit like asynch i/o.  I meant
> that in the sense that with asynch i/o you request something get on with
> your life and react to it later.
> 

I was confused between the client needing to be aware of concurrency issues,
and the client needing to *deal* with concurrency issues.  If the client
code looks like:

condition& resultAvailable = someObject.someMethod();
resultAvailable.wait();

(which is an ugly way to implement a 'future' result) then they are aware 
that there are concurrency issues being dealt with by the server.  However, 
they don't need to do anything to alleviate issues due to concurrency.  The
abstraction that they are just invoking methods is gone, but the advantage
they derive from allowing the server to handle concurrency remains.

> A future works like this too, but a little more indirectly, your future
> is your handler mechanism.  You call your function/method which returns
> a future, say boost::future< double >.  When you go to use your future
> if the value is not yet available then it blocks waiting until it is.
> If it is available then you use it.
> 

Yes, this is an attractive idea, since the abstraction I obviously enjoy
so much can be maintained :)

future<unsigned> totalItems = someObject.totalItems();
future<double> totalCost = someOtherObject.totalCost();

// blocks until all items available
double averageCost = totalCost / totalItems; 

> This would fit with an active object pattern where the method call
> returns a result quite nicely, especially if futures where compatible
> with triggering results on to the queues of other active objects.
> Though I think the asynch design approach is superior in performance,
> the semantics of a synchronous approach are often clearer as it looks
> like a traditional serial program.
> 
> This would lead to a cute pattern that I haven't seen or thought of
> before where you get a future value from an active object, but call a
> method on another active object with that future value ad infinitum and
> the results just percolate through.    

Yes, this would be currying functions across concurrency boundaries.
Love it!

> Sounds neat but a little
> impractical I think.  The traditional call a method on the Active object
> and have the results percolate through the pre-allocated workflow of
> queues and active objects makes a lot more sense.
> 

Well, I'm not actually using active objects, so I'm not so bound by common
sense :) I think it's a beautiful idea.

> Regards,
> 
> Matt Hurd

Thanks for explaining where I was going wrong.

Matt