The Perils of Concurrency [this content is outdated with the advent of Rust]

Jaideep Ganguly

Concurrency Managing concurrency is wickedly tricky for large programs. At each program point, you must reason about which locks are currently held. At each method call, you must reason about which locks it will try to hold, and convince yourself that it does not overlap the set of locks already held.

A Diverging Problem This problem is magnified because the locks you reason about are not simply a finite list in the program since the program is free to create new locks at run time as it executes. This gets worse because testing is not reliable with locks. Threads are non‐ deterministic, you can very well successfully test a program a thousand times and yet the program could go wrong the first time it runs on deployment! With locks, you must get the program correct through logic alone and that is very hard and time consuming to do so.

Will over Engineering work? Over engineering will not solve the problem. Just as you avoid locks, you cannot also put a lock around every operation. The problem is that while new lock operations remove possibilities for race conditions, itsimultaneously introduces possibilities for deadlocks. A correct lock‐using program must have neither of these. Net net, there is no good way to fix locks and make them practical to use.

Actors and Threads That is why Scala provides an alternative concurrency approach, one based on Erlang's message‐passing actors. An actor is a kind of thread that has a mailbox for receiving messages. Actors are implemented on top of normal Java threads. Java threads are not cheap. Typical Java virtual machines can have millions of objects but only a few thousand of threads. And remember, switching threads can often take thousands of processor cycles. For a program to be efficient, it is important to be sparing with thread creation and thread switching.

Example Code Below is a simple example of message passing with Actors that leverages Scala Case Classes.