Dear list,
I've got two threads that update the same location. One of them takes a lot
of time. Given this, my question is if there is a reason to prefer an atom
or a ref?
i.e.:
1) with an atom:
(def a (atom []))
;; the slow thread
(future (swap! a #(do (Thread/sleep 5000) (conj % 1
;;
Atoms are simpler, and I believe more efficient, than refs. An atom can
update itself atomically, but if you have two atoms, you cannot update both
in the same atomic transaction. With two refs, you can.
In general, it's a good idea to use atoms unless you need the additional
functionality that
Hi
I’m trying to mimic *ab* load testing (I want to see the actual errors, not
just the error count) so I created the following script:
(ns test-recycle.core
(:require [clj-http.client :as http])
(:import (java.util.concurrent Executors)))
(def url http://somehost/test.js;)
(def errors
One update taking much longer than the other, isn't optimal for either
atoms or refs.
In atoms, the faster update wins, which could randomly lead to a stream of
faster updates starving few slow updates.
I believe refs behave similarly, though if you can make your updates
commutative, you can take
Hi,
On Tuesday, September 30, 2014 12:01:33 PM UTC+2, Joachim De Beule wrote:
Dear list,
I've got two threads that update the same location. One of them takes a
lot of time. Given this, my question is if there is a reason to prefer an
atom or a ref?
is it really just two threads? Then
clojure2minizinc provides an interface between state-of-the-art constraint
solvers (via MiniZinc) and Clojure. The clojure2minizinc user models in
Clojure constraint satisfaction or optimisation problems over Boolean,
integer, real number, and/or set variables. clojure2minizinc translates
them
Apologies for forgetting the [ANN] prefix in the subject line.
Torsten
On Tuesday, 30 September 2014 20:16:00 UTC+1, Torsten Anders wrote:
clojure2minizinc provides an interface between state-of-the-art constraint
solvers (via MiniZinc) and Clojure. The clojure2minizinc user models in
