On Mon, Mar 15, 2010 at 10:41 PM, ataggart <alex.tagg...@gmail.com> wrote:
> > On Mar 15, 1:43 pm, Michał Marczyk <michal.marc...@gmail.com> wrote: > > On 15 March 2010 21:08, Meikel Brandmeyer <m...@kotka.de> wrote: > > > > > Now I'm confused. Calling ensure on r shouldn't have an effect since we > > > call alter on r anyway, no? > > > > ensure "protects the ref from modification by other transactions" > > (from the docs). alter does not. > > > > Reading into the Java code, ensure puts a lock on the ref, which, once > > in place, guarantees that the transaction doing the ensuring has an > > exclusive right to modify the ref until it commits / retries... or > > something, my Java-fu is still nothing to boast about, regrettably. > > > > At any rate, my current understanding is that, in Garth's example, the > > ensure gives (alter r f) all the time it needs to modify r's value > > while putting all other transactions which attempt to modify r on > > hold. alter, by itself, never interferes with background transactions; > > should something disappear from under its feet, it expects to be > > retried. > > > > Ok, back to improving my Java chops in the hope of grasping all the > > intricasies of Rich's code sometime... *sigh* > > > > Sincerely, > > Michał > > I'm inclined to say this is incorrect as I'm on my iphone so I can't > look at the source. The concurrency functions (e.g., ref-set, alter, > ensure) only lock their refs during the commit process. Michal is right: ensure effectively readlocks the ref -- ref-set (and alter since it is currently implemented on top of ref-set) writelocks a ref twice: the first time to "touch" it, the second time to commit. However I think it's trying to read too much in "Protects the ref from modification by other transactions" to conclude that ensure guarantees the ref to be locked. The issue Garth describes is a case of live-locking, an extant failure > mode of the STM. Some solutions would be to break up the work from > just a single transaction (though sacrificing consistency), or use the > locking construct: > > http://richhickey.github.com/clojure/clojure.core-api.html#clojure.core/locking > > One should also try to put most of the calculation outside of the transaction or to make retries cheapr (eg through partial memoization). 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
