What happens if a thread changes the value of an atom during `swap!`?

Question

According to the official Clojure docs:

Since another thread may have changed the value in the intervening time, it [swap!] may have to retry, and does so in a spin loop.

Does this mean that the thread performing the swap might possibly get stuck forever inside swap! if the atom in question never returns to the value read by swap!?

Answer 1

Yes. If you have one very slow mutation competing with a large number of fast operations, the slow operation will have to retry every time, and will not finish until all the fast operations finish. If the fast operations go on indefinitely, then the slow one will never finish.

For example, try:

(time 
  (let [a (atom 0)] 
    (future (dotimes [_ 1e9] (swap! a inc))) 
    (swap! a (fn [x] (Thread/sleep 1000) (* 2 x)))))

You'll see, first of all, that it takes a long time to finish, much longer than a second. This is because the swap! outside of the loop can't make any progress until the smaller tasks have all finished. You'll also see that the answer you get is exactly 2000000000, meaning that the doubling operation definitely happened last, after every single increment. If there were more increments, they would all get "priority".

I've additionally thought of a few cute ways to deadlock an atom forever without tying up any more threads at all!

One approach is to get the thread to race with itself:

(let [a (atom 0)]
  (swap! a (fn [x] 
             (swap! a inc')
             (inc' x))))

I use inc' so that it really is forever: it won't break after Long/MAX_VALUE.

And a way that doesn't even involve another swap! operation, much less another thread!

(swap! (atom (repeat 1)) rest)

Here the problem is that the .equals comparison in compare-and-swap never terminates, because (repeat 1) goes on forever.

Answer 2

No*. When the atom re-trys the operation, it uses the "new" value for the comparison.

You can find many examples online (like here and also here) where people have used from dozens to hundreds of threads to pound on an atom, and it always returns the correct result.

---

* Unless you have an infinite number of interruptions from competing, "faster" threads.