CODEWITHSUNDEEP
multithreadingconcurrencyclojure
Kevin Kostlan
Kevin Kostlan

Reputation: 3519

Clojure atomic derive and reset of an atom

I wrote a function to get the old value of an atom while putting a new value, all in one atomic operation:

(defn get-and-reset! [at newval]
  "Resets atom to newval and returns the old value. Atomic."
  (let [tmp (atom [])]
    (swap! at #(do (reset! tmp %) newval))
    @tmp))

The documentation says the swap! function shouldn't have side effects because it can be called multiple times. That alone doesn't seem like a problem since tmp never leaves the function and it's the last value that it gets reset! to that matters. The function seems to work but I haven't tested it thoroughly with multiple threads, etc. Is this local side-effect a safe exception to the documentation, or am I missing some other subtle problem?

Upvotes: 3

Views: 519

Answers (2)

Nathan Davis
Nathan Davis

Reputation: 5766

Yes, that will work with the current implementation of atoms in Clojure, and is (almost) guaranteed to work by contract.

The key here is that atoms are sychronous. Therefore, the inner swap! is guaranteed to complete before the outer swap!. Since tmp is only used locally, from a single thread, the inner swap! is also guaranteed not to conflict with a swap! (of tmp) on another thread.

While the outer swap! (i.e., swap! of at) could conflict with other threads, this swap! will retry when a conflict is detected. Since swap! is synchronous, these retries will occur serially w.r.t. the thread the swap! is invoked on. I suppose it's conceivable this last condition does not necessarily hold. E.g., it would be possible for an implementation of atoms to perform the swap! on a different thread, and issue retries as soon as a conflict is detected (without waiting for previous tries to finish). However, that's not the way atoms are currently implemented, and (in my opinion) doesn't seem like a very likely way to implement atoms.

If this weakness bothers you, you can use compare-and-set! instead:

(defn get-and-reset! [at newval]
  "Resets atom to newval and returns the old value. Atomic."
  (loop [oldval @at]
    (if (compare-and-set! at oldval newval)
      ;; then (no conflict => return oldval)
      oldval
      ;; else (conflict => retry)
      (recur @at))))

Upvotes: 4

Arthur Ulfeldt
Arthur Ulfeldt

Reputation: 91597

atom's cannot do what you are trying to do.

Atoms are only defined for uncoordinated syncronous updates of a single identity. for instance the functions used to update atoms may run many times so whatever you do with that value may happen many time for each value that makes it into the atom.

Agents are often a better choice for this sort of thing because If you send an action to an agent it will run at most once:

"At any point in time, at most one action for each Agent is being executed. 
Actions dispatched to an agent from another single agent or thread will occur in the order they were sent"

Another option is to add a watch to the agent or atom and have that watch react to each change after it happens. If you can convince your self that neither of these cases work for you then you may have found one of the cases where coordinated change are actually required and then refs would be the better tool, though this is rare. Usually agents or atoms with watches cover most situations.

Upvotes: 0

Related Questions