Yes, I went off the rails because I was thinking of *a lock*, instead of *the locks*, namely the read and write locks. Since readers block writers (but not the other way around), ensure grabbing a read lock on the ref means anyone wanting to get a write lock will get blocked.
On Mar 15, 3:17 pm, Christophe Grand <christo...@cgrand.net> wrote: > 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.co... > > 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
