2011/8/29 Dominikus <dominikus.herzb...@gmail.com> > Thanks a lot for this detailed analysis and the pointers to the Java > implementation, Stefan! That's excellent and very helpful. > > I still wonder, why the first transaction blocks write access. My > overall understanding of the transaction system is that changes to > referenced values remain in-transaction before committing them, a > write-lock shouldn't be needed. I'm surprised, that the second > transaction is the one who has to retry 71 times even though the first > transaction hasn't committed anything yet. >
I must confess this behaviour also challenges my assumptions. Does this work the same whatever the clojure version used ? > > Cheers, > > Dominikus > > P.S.: Thanks for the idea to use 'future' to spawn a thread! > > On Aug 29, 5:42 pm, Stefan Kamphausen <ska2...@googlemail.com> wrote: > > The call to alter already wrote to the Ref, this requires a write-lock on > > the ref (see LockingTransaction.java/doSet). After that it sleeps a > while > > and gets to its commit phase. The other transactions retries in the > > meantime. Consider the following code, which introduces some atoms for > > counting the retries > > > > (defn tz [] > > (let [rr (ref 10) > > a1 (atom 0) > > a2 (atom 0)] > > (println "Starting future") > > (future > > (dosync > > (swap! a1 inc) > > (alter rr + 100) > > (Thread/sleep 8000))) > > (println "Sleeping a bit") > > (Thread/sleep 1000) > > (println "Another dosync") > > (time > > (dosync > > (swap! a2 inc) > > (ref-set rr 1))) > > [@rr @a1 @a2 (.getHistoryCount rr)])) > > > > user> (tz) > > Starting future > > Sleeping a bit > > Another dosync > > "Elapsed time: 7001.554 msecs" > > [1 1 71 0] > > > > Note, how the 71 retries nice fit the approximately 7 seconds left and > the > > 100 miliseconds time-out (LOCK_WAIT_MSECS) for the lock used in > > LockingTransaction.java/tryWriteLock. > > > > Transactions with significantly different run-times should be avoided, > > although there is some point at which older transactions will get their > > turn. This could be another explanation of the effect. Take a look at > the > > barge-function in LockingTransaction.java > > > > Hope this helps, > > Stefan > > -- > 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 > -- 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
