> 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