What are common concurrency pitfalls? [closed]

Answer 1

Double-checked locking is broken, at least in Java. Understanding why this is true, and how you can fix it, leads you deep into understanding concurrency issues and Java's memory model.

Answer 2

One of the biggest pitfalls is the use of concurrency in the first place. Concurrency adds a substantial design/debugging overhead, so you really have to examine the problem and see if it really calls for concurrency.

Concurrency is certainly unavoidable in some domains, but when it is avoidable, avoid it.

Answer 3

This isn't a pitfall, but more of a tip based on other's responses. The .NET framework's readerwriterlockslim will dramatically improve your performance in many cases over the "lock" statement, while being reentrant.

Answer 4

Some rules of thumb:

(1) Keep an eye on the context when your declare a variable

• Write to class attributes (static) has to be synchronized
• Write to instance attributes has to be synchronized
• Keep all variables as local as possible (do not put them in a member context unless it makes sense)
• Mark variables that are read only immutable

(2) Lock the access to mutable class or instance attributes: Variables that are part of the same invariant should be protected by the same lock.

(3) Avoid Double Checked Locking

(4) Keep locks when you run a distributed operation (call subroutines).

(5) Avoid busy waiting

(6) Keep the workload low in synchronized sections

(7) Do not allow to take a client control while you are in a synchronized block.

(8) Comments! This really helps to understand what the other guy had in mind with declaring this section synchronized or that variable immutable.

Answer 5

Just found this paper, sounds interesting: A Study of Common Pitfalls in Simple Multi-Threaded Programs

Answer 6

One is race condition, which basically is assuming that one piece of code will run before / after another concurrent piece of code.

There are also deadlocks, that is code A waits for code B to release resource Y, while code B is waiting for A to release resource X.