1. Concurrency and Immutability

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

3. 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

4. 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.

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

6. Mutual Exclusion
Main Problem: Contention for shared resources

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

8. Clojure's Way:
Concurrency primitives
Future
Promises
Channels

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

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

11. 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.

12. 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.

13. 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

14. 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

15. 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.

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

17. 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

18. 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.

19. 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

20. 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.

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