Managing Complexity with Concurrent Programming - Clojure Data Analysis - page 73

We wrap this process in a call to doall to make sure that all of the processing is completed.
Remember that sequences are lazy by default, so without doall , the sequence started by
lazy-read-csv and ending in the series of map calls would be garbage collected before any
work would be done. The future-call and deref functions would never actually be called.
The @ macros in the last line would return the values of these references as originally set in the
def calls (both zero). The doall simply forces all of the processing to be done before we get to
the last line.
As this recipe shows, Clojure provides a lot of easy concurrency without having to worry
about synchronizing values, locks, monitors, semaphores, or any of the other things that
make threads and concurrency dificult and painful.
See also
We'll approach this problem again with agents, another of Clojure's concurrency tools, in the
next recipe, Managing program complexity with agents .
Managing program complexity with agents
Agents build on the STM, and each agent acts a lot like a reference. References allow you to
coordinate multiple pieces of the state, but if you only have one piece of the state that you're
updating, then that's a good use for agents. You use agents by sending them messages
(functions that manipulate the agent's state) and these are run in the thread pool, although
each agent only processes one task at a time.
We create agents with the agent function, and we send messages to them with send and
send-off . Whatever the function returns is the agent's new state value. This igure illustrates
this process:
For this recipe, we'll again solve the same problem we did in the last recipe, Managing
program complexity with STM .
Getting ready
We will include the same references in the project.clj ile and the same requirements in
the REPL as we did in the Managing program complexity with STM recipe .