Reading – Seven Concurrency Models in Seven Weeks
Just read through the book. Though it’s beta release yet, major topics are covered.
It starts with a basic thread/locking mechanism (traditional dead-locking problems on shared data), and then goes through the functional programming aspects – immutable data structures, future/promise and actors (how to divide problems into small chunks, which can be executed in concurrent and parallel). This book nicely uses several languages (Java, Closure, Elixir) to capitalize the benefits of each concurrency model.
The followings are some reading notes.
Concurrency and Parallelism
Concurrency sounds understandable, but it’s a little difficult to clearly define if we consider parallelism along with it. This book describes as follows using a quote from a presentation.
Concurrency is about dealing with lots of things at once.
Parallelism is about doing lots of things at once.
Concurrency provides a way to structure a solution to solve a problem that may (but not necessarily) be parallelizable.
As indicated in the book, concurrency and parallelism concepts are often confused and sometimes inter-mixed. I’m not confident enough yet, but concurrency may be one method to scale-out the problem solving, which is often utilized by parallel executing devices/platforms.
Concurrency in Java
Java provides built-in thread and locking mechanism, but also some libraries are provided for assisting concurrency.
- java.util.concurrent packages provides utility data structures and functions to support concurrent and parallel programming (Package java.util.concurrent)
- As indicated in “Threads and Locks” section, ConcurrentHashMap can be used to reduce the bottleneck of shared data compared with standard HashMap.
- Mutable states can be hidden inside the library functions (ex. SimpleDateFormat), and even a simple code can cause conflicts in concurrent execution. It requires caution to use multi-threading.
Actors and Object-Oriented Programming
Actors are very lightweight concurrent entities, which communicates each other with message passing.
we can think of actors as the logical extension of object-oriented programming to the concurrent world. Indeed, you can think of actors as more object-oriented than objects, with stricter message passing and encapsulation.
It’s an interesting viewpoint. The method invocation corresponds to message passing. Java’s CORBA or remote method invocation used to be discussed for providing similar concept. They didn’t go mainstream, but recent buzz around concurrency and actors might go different way.
Actors are explained with Elixir sample codes. It’s underlying erlang’s model is now applied to JVM through akka, and go-lang provides similar functionality through Goroutines. This actor model would be a major driving factor for distributed system, and could be a standard programming paradigm in near future, by partially replacing the traditional thread models.
Reducer in Closure
Closure’s reducer can provide the benefit of concurrent execution (for map-reduce type ones) along with functional simplicity.
There’re a lot of large-scale system topics lately. The distributed query system Presto may be one example. Or, New Relic’s Rubicon project (New Relic Analytics Aims to Speed IT Problem Solving) are another interesting project as large scale query services.
Functional programming style provides mathematical or abstract form of calculation, but recent programming languages and library functions are bringing these into the practical world. It’s interesting to see how the programming will be structured in 5 years later.