Alternative to Actor model

Question

My main experience working with multithread environment was using Scala, so if I had an object that was concurrently updated by multiple threads I always used Akka. Now working in Java environment I don't want to bring all Akka dependencies and futures complications for a simple case where I have a concurrently updated object. I question myself, what is the accepted alternative besides Actor model for sharing updateable state between threads?

Answer 1

Three paradigms in common use are actors (e.g. Akka), Software Transactional Memory (e.g. Clojure) or traditional manual lock-wrangling. They all have their own challenges.

Traditional lock-based programming involves detecting the places that need protection from corruption via concurrent accesses, protect them via locks, and hope that your solution is correct, deadlock-free and efficient. (Venkat Subramaniam calls this "synchronize and suffer"). There are a lot of problems with this approach: many languages give you virtually no help in ensuring correctness. Development doesn't scale because thread-safety isn't preserved under composition (every time you change anything about your code you have to re-prove that the solution is correct). Although this model underlies all other models, it is effectively the assembler programming of concurrency, and just as unpleasant to work with.

Actors you already know. The fundamental concepts here are asynchronous messages and exclusive responsibility of an actor for its bit of mutable state. The watchword is isolated mutability. One of the problems with this is that it can get very inefficient if one of the resources hidden behind an actor is a bottleneck. And it's still possible to create deadlocks when using actors improperly.

Software Transactional Memory is best viewed as shared immutability. The usual explanation is that every thread just does what it wants to do and a monitor undoes the entire sequence of one thread if it detects that a conflict has actually occurred. A nice metaphor is updating a web service with no downtime: you simply set up a second, identical server, upgrade that, and if it worked you throw a switch to redirect all traffic to the new address and shut down the old one. If something unforeseen happened (e.g. requirements changed before you were done upgrading) you simply discard the new server and start over.

The disadvantage with STM is that all the copying needed to maintain immutability can get expensive, and programming it can be really hard to understand. STM is basically lock-free programming with a vengeance, and lock-free programming is hard on many people's minds as it is. It often requires finding new algorithms for problems that you thought were already solved long ago. And again, it's efficient only as long as conflicts and rollbacks are relatively rare.

Which model to choose depends on many factors; my personal impression is that tool support is actually more important than the underlying paradigm. It's a lot easier to program with an unfamiliar paradigm with good language support than a familiar one with next to none.