Getting better performance with commute

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.

Getting ready

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.

How to do it…

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.

How it works…

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.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.141.3.175