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.

Reply via email to