Warren Lynn <wrn.l...@gmail.com> writes: > I have a hard time understanding why there is a need to retry when > doing "swap!" on an atom. Why does not Clojure just lock the atom > up-front and do the update?
This is just my two cents, but I think the/one big reason is that Clojure atoms just *are* non-locking STM-based synchronized references. They allow you to handle "shared, synchronous, independent state," but that's their typical use-case, not their definition. The Clojure atom is defined in terms of mechanism, not application. If you want locks, the Java standard library has locks aplenty. My understanding of the Clojure idiom is that when "traditional" threads-locks-and-queues concurrency is the best fit for the job, then just use it. My reading of the standard library suggests a strong preference for using higher-level constructs which leverage shared thread pools (futures and agents) over raw threads, but absolutely no shame in using e.g. LinkedBlockingQueue. Here's my quick stab at something implemented atop Java read-write locks: https://gist.github.com/3135772 -Marshall -- 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
