> Why is it so? Does not the reader just get a snapshot copy of the atom state
> and does not care who writes to the original atom? If a lock is needed, it
> is only needed for a very short commit time (cannot read when a writer is
> committing), but not during the whole "swap!" function. That still sounds a
> lot better than re-try to me.
Well let's examine the very common case:
(def a (atom {}))
(defn add-kv [k v]
(swap! assoc k v))
If I call add-kv from multiple threads, how can I assume that the map
won't be modified in the middle of the assoc? Sure, I could lock, but
read this article first:
http://en.wikipedia.org/wiki/Non-blocking_algorithm
The idea is that with atoms there will always be some progress. Even
if one updater takes an hour to complete, the other threads can
continue as needed. True that single thread will not complete until
there is a 1 hour window, but that's where other synchronization
methods come into play (worker queues, for example).
Timothy
--
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
