Functional Programming for Java Developers

Chapter 4. Functional Concurrency

Now that we have discussed functional data structures and algorithms, let’s return to the topic that has sparked widespread interest in functional programming in the first place: concurrency. Recall this warning from Chapter 1:

Warning

Multithreaded programming, requiring synchronized access to shared, mutable state, is the assembly language of concurrency.

We’ve already discussed how immutable values make synchronization unnecessary. Yet, mutating state is never completely avoidable. Let’s examine two higher-level abstractions that provide “principled” ways to manage mutable state in thread-safe ways: Actors and Software Transactional Memory.

The Actor Model

The Actor model isn’t really a functional approach to concurrency, but it fits our general goal of managing state mutation in principled ways. In the Actor model of concurrency, work is coordinated by message passing between “actors.” Each actor has a queue, sometimes called a mailbox, for incoming messages. The actor processes each message, one at a time. Carl Hewitt and collaborators developed the actor model almost 40 years ago [Hewitt1973]. [Agha1987] provides a complete description of the theory of actors. Perhaps the best known implementation of actors is found in Erlang, where actors are the core of everything you do in the language.

It’s interesting to note that Alan Kay’s original vision for objects in Smalltalk is much closer to the actor model than it is to the objects found in most languages ...