What are common concurrency pitfalls? [closed]

Answer 1

As stated in other answers, the two most likely problems are deadlocks and race conditions. However my main advice would be that if you are looking to train a team on the subject of concurrency I would strongly recommend getting some training yourself. Get a good book on the subject, don't rely on a few paragraphs from a website. A good book would depend on the language you are using: "Java Concurrency in Practice" by Brian Goetz is good for that language, but there are plenty of others.

Answer 2

It all comes down to shared data/shared state. If you share no data or state then you have no concurrency problems.

Most people, when they think of concurrency, think of multi-threading in a single process.

One way to think about this is, what happens if you split your process into multiple processes. Where do they have to communicate with each other? If you can be clear on where the processes have to communicate with each other then you have a good idea about the data they share.

Now, as mental test, move those multiple processes onto individual machines. Are your communication patterns still correct? Can you still see how to make it work? If not, one might want to reconsider multiple threads.

(The rest of this doesn't apply to Java threading, which I don't use and therefore know little about).

The other place where one can get caught, is, if you use locks to protect shared data, you should write a lock monitor that can find deadlocks for you. Then you need to have your program(s) deal with the possibility of deadlocks. When you get a deadlock error your have to release all of your locks, backup, and try again.

You are unlikely to make multiple locks work well otherwise without a level of care which is quite rare in real systems.

Good luck!

Answer 3

One truth to keep in mind is that even if the initial developers get their tasking model working properly (which is a big if), then the maintenance team that follows will surely screw things up in unimaginable ways. The take-away from that is to limit the traces of concurrency throughout your system. Do your best to make sure that most of your system is blissfully unaware that concurrency is occurring. That gives fewer opportunities for people unfamiliar with the tasking model to inadvertently screw things up.

Too often people go thread/task crazy. Everything works on its own thread. The end result is that nearly every piece of code has to be intimately aware of threading issues. It forces otherwise simple code to be littered with locking and synchronization confuscations. Every time I’ve seen this, the system eventually becomes an unmaintainable mess. Yet, every time I’ve seen this, the original developers still insist it was a good design:(

Like multiple inheritance, if you want to create a new thread/task then assume you are wrong until proven otherwise. I can’t even count the number of times that I’ve seen the pattern Thread A calls Thread B thenThread B calls Thread C then Thread C calls D all waiting for a response from the previous thread. All the code is doing is making long-winded function calls through different threads. Don’t use threads when function calls work just fine.

Always remember, Message Queues are your best friend when you want to work concurrently.

I have found that creating a core infrastructure that handles nearly all the concurrency issues works best. If there are any threads outside of the core infrastructure that must talk to another piece of software then they must go through the core infrastructure. That way the rest of the system can remain concurrency unaware and the concurrency issues can be handled by the person(s) who hopefully understand concurrency.

Answer 4

I teach concurrency a lot to my friends and co-workers. Here are some of the big pitfalls:

• Assuming that a variable that is mostly read in many threads and only written in one thread doesn't need to be locked. (In Java, this situation may result in the reading threads never seeing the new value.)
• Assuming that the threads will run in a particular order.
• Assuming that the threads will run simultaneously.
• Assuming that the threads will NOT run simultaneously.
• Assuming that all of the threads will make forward progress before any one of the threads ends.

I also see:

• Big confusions between thread_fork() and fork().
• Confusions when memory is allocated in one thread and free()d in another thread.
• Confusions resulting from the fact that some libraries are threadsafe and some are not.
• People using spin-locks when they should use sleep & awake, or select, or whatever blocking mechanism your language supports.

Answer 5

In my experience, many (skilled) developers lack foundational knowledge about concurrency theory. The classic textbooks on Operating Systems by Tanenbaum or Stallings do a good job in explaining the theory and implications of concurrency: Mutual exclusion, synchronization, deadlocks and starvation. A good theoretical background is mandatory to successfully work with concurrency.

That being said, concurrency support varies greatly between programming languages and different libraries. Furthermore, test-driven development doesn't get you very far in detecting and solving concurrency problems (although transient test failures indicate concurrency issues).

Answer 6

Here is a great resource about concurrency, specifically in Java: http://tech.puredanger.com/ Alex Miller lists many different issues one can encounter while dealing with concurrency. Highly recommended :)