How to deal with Concurrency before you start coding [closed]

Question

I'm midway through programming a Java program, and I'm at the stage where I'm debugging far more concurrency issues than I'd like to be dealing with.

I have to ask: how do you deal with concurrency issues when setting out your program mentally? In my case, it's for a relatively simple game, yet issues with threads keep popping up - any quick-fix almost certainly leads to a new issue.

Speaking in very general terms, what techniques should I use when deciding how my application should 'flow' with out all my threads getting in a knot?

Answer 1

Concurrency boils down to managing shared state.

"All concurrency issues boil down to coordinating access to mutable state. The less mutable state, the easier it is to ensure thread safety." -- Java Concurrency in Practice

So the question you must ask yourself are:

• What is the inherent shared data that the my application will need?
• When can a thread work on a snapshot of the data, that is, it momentary work on a clone of the shared data?
• Can I identify known pattern and use higher-level abstraction rather than low-level locks and thread coordination, e.g. queues, executor, etc. ?
• Think of a global locking scheme as to avoid deadlock and have a consistent acquisition of locks

The simplest approach to manage shared state is to serialize every action. This coarse-grained approach results however into a high lock contention and poor performance. Managing concurrency can be seen an optimization exercise where you try to reduce the contention. So subsequent questions are:

• How would the simplest approach be?
• What are the simple choice that I can make to reduce contention (possibly with fine grained locking) and improve performance without making the solution overly complicated?
• When am I going too fined-grained, that is, the complexity introduced isn't worth the performance gain?

A lot of approach to reduce contention rely on some form of trade-off between what would be necessary to enforce the correct behavior and what is feasible to reduce contention.

• Where can I relax a few constraint and accept that sometimes stuff won't be 100% correct (e.g. a counter) ?
• Can I be optimistic and deal with conflict only when concurrent modifications happen (e.g. using time stamp and retry logic - that's what TM do)?

Note that I never worked on a game, only on server-side part of enterprise apps. I can imagine that it can be quite different.

Answer 2

I use immutable data structures as much as possible. About the only time I do use mutable structures is when I have to such as with a library that will save a boatload of work. Even then I try to encapsulate that library in an immutable structure. If things can't change then there's less to worry about.

I should add that some things to keep in mind on your future endeavors are STM and Actor models. Both of these approaches to concurrency are showing very good progress. While there is some overhead for each, depending on the nature of your program that might not be an issue.

Edit:

Here are a few links to some libraries you could use in your next project. There's Deuce STM which as the name implies is an STM implementation for Java. Then there's the ActorFoundry which as the name implies is an Actor model for Java. However, I can't help but make the plug for Scala with its built in Actor model.