On Sun, Aug 2, 2009 at 8:54 PM, Mark Volkmann<r.mark.volkm...@gmail.com> wrote: > > On Sun, Aug 2, 2009 at 5:45 PM, Rich Hickey<richhic...@gmail.com> wrote: >> >> On Sun, Aug 2, 2009 at 3:20 PM, Mark Volkmann<r.mark.volkm...@gmail.com> >> wrote: >>> >>> The doc for commute says "At the commit point of the transaction, sets >>> the value of ref to be: >>> (apply fun most-recently-committed-value-of-ref args)". >>> >>> Looking at the source code in LockingTransaction.java, that doesn't >>> seem to always be the case. I see this: >>> f.fn.applyTo(RT.cons(vals.get(ref), f.args)) >>> >>> vals is a HashMap of in-transaction values, not most recently committed >>> values. >>> >>> Inside a transaction, Refs get in-transaction values if you do a >>> ref-set or alter on them. >>> Within a transaction you can ref-set or alter a Ref and then do a >>> commute on the same Ref. >>> You can't reverse the order. Once you do a commute on a Ref, you can't >>> do a ref-set or alter on it in the same transaction. >>> >>> During transaction commit and immediately before the commute functions >>> for the Ref are called, it determines whether the Ref has an >>> in-transaction value, meaning that ref-set or alter was called on it. >>> If it does not then the most recently committed value for the Ref is >>> used for the in-transaction value. >>> >>> So I think it is only partially true to say that when commute >>> functions are rerun during a commit, they use the most recently >>> committed values of Refs. That only happens if ref-set and alter were >>> not used on the Ref before the call to commute. >>> >>> Am I understanding this correctly? >>> >> >> Not really. If this transaction is succeeding, and it has written to a >> ref prior to its commute, then those writes *are* the most recently >> committed value, committed now as a prior part of the same >> transaction. > > Thanks for explaining that! I see what you're saying, but I also see > how someone, like me ;-), could be confused by the doc string. > > When the code in question is running, the commit hasn't completed yet. > It doesn't seem correct to say "those writes *are* the most recently > committed value", but rather "those writes *will become* the most > recently committed value. I hope I'm not just splitting hairs, but it > seems that "most-recently-committed-value-of-ref" implies that its a > value that can be seen now by all threads. > > Maybe this is splitting hairs too, but if the code in a commute > function throws an exception when it is called during the commit then > values set before the commutes in the transaction body really will not > become the most recently committed value. >
Nor will the commute happen. Rich --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
