If so, there's more to be explained about `commute'. I'm imagining the
commit-time rules saying that if competing changes to the refs touched
by `commute' can be ignored, because the changes can be applied in
either order. But if the operation was something like `inc', two
competing threads would both commit a value one greater than when both
transactions started, which would result in a final value only one
greater, rather than two, as intended.
Reading the documentation again, I think these characterizations are
wrong. It sounds like `commute' runs /again/ at the commit point of
the
transaction, but the whole transaction doesn't have to run again. It's
not clear whether `commute' /always/ invokes the provided function
twice,
or only in the case of having detected a conflict against the target
ref
at the would-be commit point.
Hi Steven,
It is mort important to focus on the semantics (commutative or last-
one-wins) than the implementation details. If you care about ordering,
stick to alter. If you aren't sure, stick to alter. :-)
I find a counter to be a useful example. If the purpose of the counter
is to keep a total count of something that happened, then you can use
commute. But if the counter is used as an id generator within the
transaction, then order matters and you have to use alter.
Stu
--
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
