Concurrency and Immutability

Concurrency vs. Parallelism Concurrency is being able to juggle multiple tasks at the same time Parallelism is begin able to execute multiple tasks simultaneously

Concurrency vs. Parallelism Concurrency has been an issue for several decades (even on single-core machines). Slow operations can run in the background I/O Expensive computations

Concurrency vs. Parallelism Now it's common to have multiple cores on laptops and phones Making full use of the hardware requires splitting your task amongst those cores.

Concurrency vs. Parallelism Despite their differences, the programming issues of concurrency and parallelism are fairly similar.

Mutual Exclusion Main Problem: Contention for shared resources

Mutual Exclusion Main Problem: Contention for shared resources Solution: Mutual exclusion Locks Semaphores Etc.

Clojure's Way: Concurrency primitives Future Promises Channels

Future A future provides a way of referencing a specific result that is (presumably) being computed in parallel (future (println "starting computation") (Thread/sleep 5000) (println "finished computation") 42)

Future The value computed by a future can be accessed by calling deref The thread will block until the value becomes available You can put a limit on the amount of time to wait And a default value to return if it times out You can also check for availability with (realized? <future variable>)

Promise Similar to a future It defines a placeholder for a value to be computed later The difference is that any thread could potentially deliver a value to the promise Once a value has been delivered all future deliver calls are ignored.

Atom A holder for values that may change. The values are still immutable but one thread can change an atom's value and any future reads from that atom (even by another thread) will reflect the new value.

swap! The exclamation-point ending is a longstanding LISP convention to indicate an impure function The official rule in Clojure is that it should be used for any function that isn't legal in an STM* transaction *more about this later

swap! Provides a safe way to make a change to an atom Even if other threads may be modifying the atom It takes an atom as its first argument and an update function as its second argument The update function takes the old value and uses it to compute the new value This is particularly useful for adding/removing elements to/from collections

reset! Used when you don't care about the previous value. Takes an atom as its first argument and the new value as its second argument.

STM - Software Transactional Memory swap! can only be used to update a single atom, but sometimes you need to modify several atoms simultaneously

STM For example, if there were three containers Source Dest1 Dest2 And two threads taking elements from Source the first places elements into Dest1 the second places elements into Dest2 We want to be sure that each element ends up in either Dest1 or Dest2, but not both

STM If we are quite unlucky, the same element could be read from Source by both thread1 and thread2 before the other modified Source to indicate what it had taken.

STM: ref References are like atoms, but they can be used in STM transactions They are modified with alter which is just like swap! but is safe for use in STM transactions hence the lack of exclamation point

STM: dosync STM transactions take place within the body of a dosync statement. If any of the references read in a dosync block are modified, the dosync block re- executes This can lead to starvation if there is a slow dosync block contending with a number of fast ones.

Core.async Inspired by the 'go' language Which was inspired by CSP Communicating Sequential Processes Define channels that carry data between processes