How are message-passing concurrent languages better than shared-memory concurrent languages in practice

Question

I've been a Java developer for many years but never had to deal too much with concurrency issues until I started doing Android development, and suddenly started finding "application not responding" and apparent deadlock situations.

This made me realize how hard it can be to understand and to debug some of these concurrency issues. How do new languages such as Scala and Go improve concurrency? How are they more understandable and how do they prevent concurrency bugs? Can someone provide real-world examples that demonstrates the advantages?

Answer 1

The three main contenders for simplifying concurrency are actors, software transactional memory (STM), and automatic parallelization. Scala has implementations of all three.

Actors

Actors find their most notable implementation in the language Erlang, which as far as I know is where the idea started*. Erlang is designed from the ground up around actors. The idea is that actors themselves are black boxes to each other; they interact only by passing messages.

Scala has an implementation of actors in its library, and variants are available in external libraries. In the main library, the black-box-ness is not enforced, but there are easy-to-use methods for passing messages, and Scala makes it easy to create immutable messages (so you don't have to worry that you send a message with some content, and then change the content at some random time).

The advantage of actors is that you don't have to worry about complex shared state, which really simplifies the reasoning involved. Also, you can decompose the problem into smaller pieces than threads and let the actor library figure out how to bundle actors into the appropriate number of threads.

The downside is that if you are trying to do something complex, you have a lot of logic to deal with for sending messages, handling errors, and so on, before you know it succeeds.

Software Transactional Memory

STM is based on the idea that the most important concurrent operation is to grab some shared state, fiddle with it, and write it back. So it provides a means of doing this; however, if it encounters some problem--which it typically delays detecting until the very end, at which point it checks to make sure the writes all went correctly--it rolls back the changes and returns a failure (or tries again).

This is both high-performance (in situations with only moderate contention, since usually everything goes just fine) and robust to most sorts of locking errors, since the STM system can detect problems (and even potentially do things like take access away from a lower-priority request and give it to a higher-priority one).

Unlike actors, it's easier to attempt complex things, as long as you can handle failure. However, you also have to reason correctly about the underlying state; STM prevents rare unintentional deadlocks via failing and retrying, but if you've simply made a logic error and a certain set of steps cannot complete, STM cannot allow it to.

Scala has a STM library that is not part of the standard library but is being considered for inclusion. Clojure and Haskell both have well-developed STM libraries.

Automatic Parallelization

Automatic parallelization takes the view that you don't want to think about concurrency; you just want stuff to happen fast. So if you have some sort of parallel operation--applying some complex operation to a collection of items, one at a time, and producing some other collection as a result, for instance--you should have routines that automatically do this in parallel. Scala's collections can be used in this way (there is a .par method that converts a conventional serial collection into its parallel analog). Many other languages have similar features (Clojure, Matlab, etc.).

---

Edit: Actually, the Actor model was described back in 1973 and was probably motivated by earlier work in Simula 67 (using coroutines instead of concurrency); in 1978 came the related Communicating Sequential Processes. So Erlang's capabilities were not unique at the time, but the language was uniquely effective at deploying the actor model.