The STM system we created in the first recipe of this chapter, Managing program complexity with STM, has one subtle problem: threads attempting to reference and update total-hu
and total-fams
contend for these two values unnecessarily. Since everything comes down to accessing these two resources, a lot of tasks are probably retried.
But they don't need to be. Both are simply updating those values with commutative functions (#(+ sum-? %)
). The order in which these updates are applied doesn't matter. Since we block until all of the processing is done, we don't have to worry about the two references getting out of sync. They'll get back together eventually, before we access their values, and that's good enough for this situation.
To update references with a commutative function, instead of alter
, we use commute
. The alter
function updates the references on the spot, while commute
queues the update to happen later, when the reference isn't otherwise engaged. This prevents contentions on those references and can make the system faster too.
For this recipe, we'll again look at the problem we did in the Managing program complexity with STM recipe.
Everything is going to be the same as it was for Managing program complexity with STM. We'll use the same dependencies and requirements and even most of the functions as we did for that recipe.
In fact, the only change will be for the update-totals
function, and even that change is minor:
(defn update-totals [fields items] (let [mzero (mapv (constantly 0) fields) [sum-hu sum-fams] (sum-items mzero fields items)] (dosync (commute total-hu #(+ sum-hu %)) (commute total-fams #(+ sum-fams %)))))
Do you see the difference? We just used commute
instead of alter
. That's the only change we need to make.
Now the references are updated after the dosync
. With alter
, the changes happen inside the dosync
, within the same transaction. However, with commute
, both changes are run separately, and both are scheduled to run when Clojure knows there will be no conflicts. Depending on the use case, this can dramatically cut down on the number of retries and speed up the overall program.
3.141.3.175