Hi Rob,
That sounds quite interesting - chains of promises until the results start flowing. It should be easy to adapt the http://onsmalltalk.com/programming/smalltalk/smalltalk-concurrency-playing-w... example implementation to do the same kind of deferral.
Of all the classes of possible deadlocks which do the E promises help resolve? (Please don't say all unless you back up such a general statement with a proof. Thanks).
All the best,
Peter
Rob Withers wrote:
That's a nice example. The difference with E's promises is that a Promise doesn't block for value, it sends the new msg eventually and returns a second promise. The way I have this implemented in SqueakElib, is you send #eventual to get an eventual ref, then you can send a msg to the eventual ref, returning a promise, which you can then send a second msg to, returning a second promise.
| promise1 promise2 | promise1 := anObject eventual foo. promise2 := promise1 bar. promise1 whenResolved: [:val | Transcript show: ' foo: ', val printString]. promise2 whenResolved: [:val | Transcript show: ' bar: ', val printString]. Transcript show: 'sent foo bar...'
This prevents deadlocks. This is also very interesting when looked at in a distributed system, using Promise Pipelining. Let us say that anObject resides in Vat B on a different machine. Instead of having a 2 round trip communications situation, we have 1 round trip. So instead of
- send #foo, 2) receive fooResult, 3) send bar, 4) receive barResult
We have:
- send #foo, 2) send #bar to fooResultPromise, 3) receive barResult.
Where #foo and #bar are both sent to the objects in VatB. They are sent in the same packet.
Rob
----- Original Message ----- From: "Peter William Lount" peter@smalltalk.org To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Saturday, October 27, 2007 11:21 AM Subject: Concurrent Futures
Hi,
This link will be of interest to those wanting easy concurrency. Works best for simple cases and can be used as a primitive in building up more complex concurrency controls. However, use with caution, especially when larger amounts of code are being executed that could conflict with other threads is involved. This applies even in the single native thread multiple Smalltalk "light weight green" processes environment of most Smalltalks.
http://onsmalltalk.com/programming/smalltalk/smalltalk-concurrency-playing-w...
Cheers,
Peter