RE: [boost] Re: Future of threads (III)
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 ;-) 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. 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. 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. :-) 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. Regards, Matt Hurd _______________________ Susquehanna Pacific P/L hurdm@sig.com +61.2.8226.5029 _______________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
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
participants (2)
-
Hurd, Matthew -
Matthew Vogt