5

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?

15

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.

| improve this answer | |
  • 9
    +1. The problem is shared mutable state. The solutions are to either control sharing, control mutation, or both. Different paradigms live on different points of this 2D space. You summarized the positions nicely! – Jörg W Mittag Nov 6 '17 at 18:06
  • 2
    @JörgWMittag didn't you just summarize it better? – whn Nov 7 '17 at 14:18
  • Can we create a paradigm so heavy that we cannot lift it? It is too bad about how computers support mutability. Bricks have worked so well for thousands of years, even with multiple concurrent updates to them. – user251748 Nov 27 '17 at 18:41
  • omg rust!!11111 – Matt Joiner Dec 11 '19 at 1:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.