Hi, Thanks for all suggestions. It all encouraged me to deep dive into atom-s code which turns out to be a simple wrapper over Java java.util.concurrent.atomic.AtomicReference which essentially is a spinlock. Knowing how it works under the hood makes so easier to use it ...
Below piece (hopefully correct) let me update map atomically: (defn cond-assoc! [atomic-map key val] (loop [] (let [candidate (if (contains? @atomic-map key) @atomic-map (assoc @atomic-map key val))] (if (compare-and-set! atomic-map @atomic-map candidate) candidate (recur))))) I also learned that using future (or essentially Java threads) is so poor approach to scalability. derefing memoized delay of my function wrapped with future worked well to some point. After pushing it a bit with more concurrent tasks, my JVM started freezing under pressure of to many threads. I ended up with my custom hybrid of a queued future-s. I have also a version done in core.async - I will try to write it up in a separate piece at some point .. Best regards, Andy -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.