Well it definitely seems that ensure has the behavior Michal described, because the ensure code I posted works. I'm glad this behavior is available, because I don't think there is any other way to achieve the combination of synchronization and locking I need. (I couldn't get locking to work on a ref; see my original msg.)
Maybe the two different behaviors call for different constructs: one for making sure an unmodified ref hasn't changed at commit time (the original purpose I thought ensure was supposed to serve), and one with the behavior I need here, namely causing all other modifications to block for the remaining life of the transaction. On 3/15/10, 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. The ensure > function is provided to add a *non-changing* ref to the set of refs > that need to be locked; ref-set, etc., do this implicitly. To lock > the refs upon first use would largely obviate the point of the STM. > > 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 > > -- > 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 > -- Sent from my mobile device -- 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
