On Mar 1, 2009, at 1:53 PM, Anand Patil wrote:
> > Hi all, > > My concurrent dabblings in Clojure have been a real pleasure so far. > In terms of concurrency, it's just in a completely different league > from any other language I've tried. However, I think agents could be > made even more friendly by allowing them to temporarily surrender > their place in the thread pool pending another computation. > > Specifically, I'm thinking of a function 'yield' called as (yield > other-agent msg-fn args) from within agent actions. If agent a yields > to agent b, a gets off the thread pool and msg is sent to b with given > args. When b finishes executing the message, the yield call returns > b's new value, and a gets back on the thread pool. > > I _think_ the language could prevent deadlocks by: > - making agents not take any messages while they are 'yielded' > - keeping a 'yield stack' and checking that no cycles happen. > > Here are two use cases for yield: > > 1) Say an 'auto-agent' cell needs to run an expensive, parallelizable > computation to update its value. Without yield you could do this by > dispatching the action with send-off, or by splitting the cell up into > multiple cells, each handling a chunk of the computation. Yield would > be nicer than both: send-off spawns an expensive kernel thread (as I > understand it) and breaking up the cell complicates the dataflow model > unnecessarily. > > 2) Currently this program, which creates a tree of dependent futures, > deadlocks on my 8-core mac pro: > > (def breadth 4) > > (defn with-deref [fun] > (fn [& x] (apply fun (map deref x)))) > > (defn future-tree [depth] > (if (= depth 0) (future 1) > (let [new-futures (map future-tree (repeat breadth (- depth > 1)))] > (future (apply (with-deref +) new-futures))))) > > ; WARNING: This deadlocks on 8-core Mac Pro! > (future-tree 4) > > I'm guessing it deadlocks because the thread pool fills up with > futures that aren't ready to go, but it feels like the language should > be able to avoid the deadlock without requiring the programmer to > think about how many threads are actually in the thread pool. If > futures were based on agents, which yielded when deref-ing other > futures, the deadlock wouldn't happen. > > I have no idea how hard it would be to implement yield, as I have very > little practice with Java. Thoughts? > I've made futures use the Agents' CachedThreadPool, which should prevent the thread pool exhaustion (svn 1316). You shouldn't worry about the expense of the threads, that's why there's a pool. Yield as you've described it is definitely not going to happen. Rich --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
