Clojure atomic derive and reset of an atom

Question

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?

Since you are not using the current (soon to be old) value, why must the operation be atomic? If you used the old value to compute the new one, such that a transaction were required, the operation would need to be atomic. But you're just resetting a value, without using the prior one. All you really need to do is (let [old @at] (reset! at newval) oldval) .. or, did I miss your intent? — Josh
– Josh, Commented Oct 2, 2016 at 14:24
@Josh It seems like he does use the "current (soon to be old)" value, just that it's being used outside of the call, and wants to see all values that the atom had. With your proposed solution, there could be problems. Imagine there were two (or more) threads calling get-and-reset!. If they both deref the atom before each other can reset!, they would both return the same value, meaning one of the values that the atom had would never be returned. — Hoagy Carmichael
– Hoagy Carmichael, Commented Oct 3, 2016 at 10:00
It looks like you're trying to get the equivalent of reset!, but return the old value instead. You might want to look at: dev.clojure.org/jira/browse/CLJ-1454 and dev.clojure.org/jira/browse/CLJ-1599. — John Szakmeister
– John Szakmeister, Commented Oct 3, 2016 at 10:01
@HoagyCarmichael yes, there is a race condition, and I guess I can see a case for the need to return the "correct" old value, though it seems rather arbitrary since the old value is not used in setting the new value. In reality swap! would be used, but if we imagine that instead of that, we did (reset! at (inc oldval)) then of course we need to synchronize. But we essentially "throw away" old value, so the moment it is read seems rather unimportant. In many use cases my suggestion would be perfectly valid, but for some maybe it would not, if some order of returned old values was important — Josh
– Josh, Commented Oct 3, 2016 at 12:28

Nathan Davis · Accepted Answer · 2016-10-04 16:47:56Z

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))))

Arthur Ulfeldt · Accepted Answer · 2016-10-04 00:33:30Z

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.

Atoms definitely can do this. See the proposed enhancements targeting this specific use case that @jszakmeister mentioned.

Collectives™ on Stack Overflow

Clojure atomic derive and reset of an atom

2 Answers 2

Comments

1 Comment

Hot Network Questions

Collectives™ on Stack Overflow

2 Answers 2

Comments

1 Comment

Related