On Mon, Mar 15, 2010 at 11:24 PM, Garth Sheldon-Coulson <g...@mit.edu>wrote:
> Christophe, thanks for the partial memoization tip. I think that would > work in many cases, but for my current use case I really need to put a > lock on the ref, because the function is very expensive and other > threads will be updating it with previously unseen values so quickly > that memoization can't help. Are you saying that the fact that ensure > works in my example isn't to be counted on? > Ensure seems to mitigate the problem but I think that with a different timing and bad luck (which always happen under load in concurrent systems), you may still experience a high-level of retries. (The readlock fastened by ensure is released just after the computation of f for alter to writelock it, tag it and release the lock. So there are two moments where the current transaction can be barged by another (older) transaction.) Two questions: Do you care about the return value of the long running computation inside the transaction? Does this computation depends on the value of other refs? If you anwser no to both, you should consider commute. If you answered no only to the first, a delay may help you (by making the transaction shorter): (dosync (alter r #(delay (f @%)))) ;; don't forget to capture all the ref values you depend on hth, Christophe -- 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 Note that posts from new members are moderated - please be patient with your first post. 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
