Clojure Course - Concurrency

Clojure Course

Part 6 - Concurrency

First let's review what concurrency is all about, and why it is a big deal.

Traditional programming is sequential: we give the computer a series of instructions, which are executed one by one, in specific order, by the CPU.

But computing tasks have become increasingly complex and time-consuming. The technological evolution of hardware has taken us to a level, where the speed of microprocessors cannot be improved much further. So modern computers are made with multiple CPU cores. The evolution of networking and distributed computing also enables us to run programs across a large number of machines at the same time.

Modern programming languages must provide tools to deal with this in simple and efficient ways, to support concurrent and parallel programming. This programming style can have huge benefits for difficult and time-consuming calculations, and for dealing with data spread across multiple computers. But it has several pitfalls and dangers, especially when shared state is involved, for example race conditions and deadlocks.

Fortunately, Clojure has a great variety of tools to handle concurrency. In fact, this is one of Clojure's strongest points and fundamental design principles! A detailed study on all of these features would be too much for this lesson, but let's get a quick glance across the board!

Remember that Clojure runs on host platforms.

On the JVM, we can access Java's native threading, locking and concurrency capabilities, however there is little reason to do so, unless we want to interface with existing code written in Java.
Even though JavaScript is inherently single-threaded, most of these features even make sense and are available in ClojureScript, but some are not implemented.

Shared State

As we have seen, most things in Clojure are immutable. But to help with concurrency, we can use some mutable objects too. The most popular concurrency tool is the atom.

An atom is a mutable reference to an immutable value. We can change the reference to point to a different value, using the swap! or the reset! functions. It works very similarly to a variable that we normally use in other languages. But there is a bonus: it is thread-safe, so its value can be updated only by one thread at a time. The locks and retries are automatic. This eliminates a lot of template code and potential bugs already, at least as long as we take advantage of Clojure's immutable data types and pure functions!

We can read (de-reference) the current value behind the atom, using the deref function. The shorthand symbol for (deref x) is: @x (simply prepend the at sign, no parens needed).

(do
  (def x (atom 1))
  ; printing the atom just shows the reference
  
  ; dereferencing the value
  (println "Initial value:" (deref x))

  ; swap! applies a function on the existing value of the atom
  (swap! x inc)
  (println "After swap:" @x)

  ; reset! changes the value directly
  (reset! x 42)
  (println "After reset:" @x))

Transactions

A transaction is a coordinated reference, that means it has to simultaneously modify multiple values. A common example is transferring money between two bank accounts: the transaction is completed only when one account balance is credited and the other one is debited. A partially completed result is unacceptable.

Clojure can deal with this sort of operation in a secure way. We can define multiple refs, and we can alter them inside a dosync block to complete a transaction.

; define two RPG characters, tracking their gold
(def shopkeeper (ref 1000))
(def adventurer (ref 78))

; sell something for 50
(dosync
  (alter adventurer - 50)
  (alter shopkeeper + 50))

; verify the result of the transaction
(deref shopkeeper)  ; 1050
(deref adventurer)  ; 28

This code is only an illustration. ref is not implemented in ClojureScript, so this works only on the JVM.

Delay, Promise, Future

These three tools help us, in terms of concurrency, dealing with:

the definition of a task,
the execution of a task,
and the retrieval of the result.

Sometimes we have a complicated and long calculation in our program, that we don't even need to do most of the time, just on-demand. The delay is perfect for this situation.

When we define the delay, we provide the way how to calculate the value.
It is not executed immediately, only when we deref the delay.
It is calculated only once, any subsequent dereferences will remember the cached value.
Keep in mind what we learned about referential transparency! Same input = same output! So once it is known, the value remains the same.
The delay can be safely shared among multiple threads. It can be used to make sure, that a certain task, such as sending an email or querying a database, happens only once, even if multiple threads need the same result.

(defn calculation []
  (do
    (println "Calculating...")
    (* 6 7)))
; Intended side effect, to show that
; the value is only calculated once!
; even though we deref multiple times

(def the-value (delay (calculation)))

(do
  (println "Now we retrieve the value 3 times")
  (println @the-value) ; calculation happens
  (println @the-value)
  (println @the-value))

A promise is slightly different.

When the (promise) is created, it only acts as a "coupon" for an eventual future value. But unlike the delay, at this point we don't declare how it will be calculated.
The promise is realized when we deliver a value to it. Typically, this happens in a separate thread.
A promise can be delivered only once.
We can deref the promise to retrieve the value. If the promise is not yet realized, then deref blocks the current thread and waits for the result.
If the promise is never delivered, then deref may block the execution indefinitely. To avoid this, we can set a timeout for deref.

(do
  ; declare a new promise
  (def random-prophecy (promise))
  
  (realized? random-prophecy) ; false
  
  ; deliver the value to the promise
  (deliver random-prophecy
    (rand-nth ["Fame, glory and wealth" "Blood, sweat and tears"]))

  ; deref retrieves the value (blocks until realized)
  @random-prophecy
  
  (realized? random-prophecy)) ; true

In ClojureScript the promise is not implemented, but with the JS interop we can directly create and use Javascript Promise objects.

Yet another variant of the same concept, is the future.

When declaring the future, we specify how to calculate the value.
Clojure starts the execution of the future immediately, but in a separate thread. The main thread is not blocked.
It is possible to poll the status of the future, with the realized? function.
The result is retrieved with deref. If the future is not yet realized, then this operation blocks the main thread and awaits the response.
If an error occurs during the computation of the future, it will only be thrown when the future is dereferenced.

(do
  ; Declare the future
  ; This could be a long calculation.
  ; It is executed in a separate thread.
  (def next-weeks-lottery-numbers
    (future [4 8 15 16 23 42]))
  
  ; Dereference the future
  ; This thread is blocked until the calculation is done.
  (deref next-weeks-lottery-numbers))

Parallelism with a single P

Imagine that we need to apply the same operation to a lot of data. We are already friendly with the map function, which does exactly this: one by one, it applies a function on the elements of a collection. Assuming this is a pure function, the results are independent from each other, so this is trivial to parallelize.

That is where we can use pmap instead of the regular map - the calculations will magically happen on different threads. So if we run it on a computer with 8 processor cores, the calculation can actually finish 8x faster!

; calculate squares of numbers concurrently
(pmap (fn [x] (* x x)) (range 20))

This example would not work here either, pmap is not implemented in ClojureScript, because JS in the browser is single threaded.

Lightweight concurrency

The core.async library implements a lightweight alternative to threads, inspired by the goroutines in the Go language. This actually works in Javascript too, with some limitations.

The program is broken down into small tasks.
A task runs in a separated process, represented in code by the go macro.
Tasks can communicate with each other, using channels, defined by chan.
Channels are tiny message queues. They can hold one or more values, they can suspend the supplier processes which feed more values, or surplus values can be discarded.
Sending values to a channel is done with the >! macro.
Consuming values from a channel is done with the <! macro.


(require '[clojure.core.async :refer [>! <! go chan]])

; Define a channel
(def wire (chan))

; A process that consumes and prints any value from the channel
(go (println (<! wire)))

; A process that sends a value over the channel
(go (>! wire "love letter"))

For more detail, you can check these resources:

In the next chapter we will examine the dynamic nature of executing Clojure programs, by learning about macros!

[Clojure] 06 Concurrency