Thanks. I really appreciate seeing that example. There are more answers there than even the original question . . . like how easily you time the performance and how easily you make random lists of values. . . .also the use of "remove" in that code you grabbed to avoid having two filters is totally slick. I agree that agents seemed a little heavy-weight, too.
Just to understand ... 'send-future' works too but you don't think that's the way to go? Also, I need to see if the Java code has a place for a user to specify the thread pool size. Otherwise is that best handled by send-off-future wrapping a generator that can throttle or something? Thanks again. On Fri, Jan 23, 2009 at 4:35 AM, Timothy Pratley <[email protected]>wrote: > > > > On Jan 23, 11:24 am, e <[email protected]> wrote: > > wow. I wonder if I could use this for the quicksort I was talking about. > > Interesting question. I can't think of an elegant way to implement an > agent based parallel quicksort because await cannot be used > recursively. So I implemented a version using Futures instead. Now you > wont be able to run this unless you modify Agent.java, search for > soloExectuor, make it public, and recompile Clojure. > > http://groups.google.com/group/clojure/web/pquicksort.clj > > Using futures like this seems convenient to me, I think it has some > benefits over just using a Thread (two pools to choose from, you can > wait for a return, you can cancel it) and making a one-shot agent just > feels a bit messy. > > > On Jan 23, 4:06 am, Emeka <[email protected]> wrote: > > Could you explain atoms the way you explained agents?\ > > Atoms provide a place to put some data. Multiple threads can update or > read this data without fear of it be 'half' updated by two threads > accessing it at once. Further more, modification of Atoms is only > available via supplying a function which takes the current value and > returns a new value. The reason for this is that even with a piece of > atomic data, if you had two threads execute A = A + A * A at the same > time, one might update A while the other was half way through its > calculation, so on the second thread it might be something like this: > Anew = Abefore + Abefore * Aafter > That would be really confusing! > So instead you update atoms by providing a fuction (swap! A (fn [x] (x > + x * x)) > A will only be set when the entire calculation has been made without A > changing in the meantime. > This is in contrast to Refs, which use transactions to coordinate > access. > > > Regards, > Tim. > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
