Books on multi-threaded programing
February 8, 2010 11:01 AM Subscribe
Is there a good book/blog/whathaveyou about defensive programing techniques to avoid deadlocks and race conditions? I'm looking for something geared towards experienced computer engineers.
I work on a fairly complex multi-threaded system where stability is very important. While everyone who works on the project understands what a deadlocks and race conditions are and what the tools exist to work around them, some of the engineers continually write code that extremely susceptible to race conditions or deadlocks. This leads to code that is overly complex, brittle and that noone wants to modify for fear of breaking.
Over the years I've developed an intuition for how to write code that by design has less of these problems, but with the exception of a few high level concepts I'm not very good at explaining exactly why a certain design is going to lead to synchronization problems, or giving good advice about how to fix code so that it won't have these kinds of problems in the future. That is, when it comes to real multi-threaded code issues, I can do, but I can't teach. I'd like to change that.
I work on a fairly complex multi-threaded system where stability is very important. While everyone who works on the project understands what a deadlocks and race conditions are and what the tools exist to work around them, some of the engineers continually write code that extremely susceptible to race conditions or deadlocks. This leads to code that is overly complex, brittle and that noone wants to modify for fear of breaking.
Over the years I've developed an intuition for how to write code that by design has less of these problems, but with the exception of a few high level concepts I'm not very good at explaining exactly why a certain design is going to lead to synchronization problems, or giving good advice about how to fix code so that it won't have these kinds of problems in the future. That is, when it comes to real multi-threaded code issues, I can do, but I can't teach. I'd like to change that.
Looks like you'd be interested in The Little Book of Semaphores.
posted by tmcw at 11:36 AM on February 8, 2010
posted by tmcw at 11:36 AM on February 8, 2010
Best answer: Doug Lea's Concurrent Programming in Java is excellent, and not as solely Java-focussed as it sounds.
Having said that, if you are interested in Java concurrency, then Java Concurrency in Practice is the ideal book.
posted by siskin at 11:39 AM on February 8, 2010
Having said that, if you are interested in Java concurrency, then Java Concurrency in Practice is the ideal book.
posted by siskin at 11:39 AM on February 8, 2010
Are you talking about database deadlock conditions? If so, what DBMS?
posted by Maisie at 11:42 AM on February 8, 2010
posted by Maisie at 11:42 AM on February 8, 2010
Seconding siskin's book recommendations.
posted by mezamashii at 11:53 AM on February 8, 2010
posted by mezamashii at 11:53 AM on February 8, 2010
Language and platform?
posted by jeffamaphone at 12:47 PM on February 8, 2010
posted by jeffamaphone at 12:47 PM on February 8, 2010
Response by poster: I intentionally didn't mention language choice because I'm not really looking for language specific information. As I said, everyone understands the tools, and the skills I'm looking for should be fairly language independent.
posted by aspo at 1:22 PM on February 8, 2010
posted by aspo at 1:22 PM on February 8, 2010
The Dining Philosophers.
Represent your resources and processes as a directed graph, with edge directions
reflecting whether a process has obtained a resource, or is requesting a resource.
If there are cycles in that graph, then there is deadlock.
Here's a nice explanation, with pictures.
posted by the Real Dan at 2:08 PM on February 8, 2010
Represent your resources and processes as a directed graph, with edge directions
reflecting whether a process has obtained a resource, or is requesting a resource.
If there are cycles in that graph, then there is deadlock.
Here's a nice explanation, with pictures.
posted by the Real Dan at 2:08 PM on February 8, 2010
It's old, but for the gory details Schimmel's UNIX(R) Systems for Modern Architectures: Symmetric Multiprocessing and Caching for Kernel Programmers is a gold mine, especially if you work on Unix systems. I kept it checked out of my employer's library for months on end when I was getting up to speed on kernel and systems programming.
Another old one that I still pull out occasionally is Butenhof's Programming with POSIX(R) Threads.
While these suggestions do treat specific implementations, the concepts are there.
posted by scatter gather at 3:12 PM on February 8, 2010
Another old one that I still pull out occasionally is Butenhof's Programming with POSIX(R) Threads.
While these suggestions do treat specific implementations, the concepts are there.
posted by scatter gather at 3:12 PM on February 8, 2010
van Roy and Haridi's Concepts, Techniques, and Models of Computer Programming
Table of Contents here.
posted by at at 6:01 PM on February 8, 2010
Table of Contents here.
posted by at at 6:01 PM on February 8, 2010
I also have and like the Butenhof which scatter gather mentioned. It is about primarily about pthreads, but the advice translates pretty well to other systems.
posted by themel at 9:45 PM on February 8, 2010
posted by themel at 9:45 PM on February 8, 2010
Language independent knowledge: don't do anything non-trivial while holding a lock. Don't access shared things without acquiring a lock.
The 100s of things that kill you are all the platform specific things. Like on Windows you can't call any functions that cause a DLL to be loaded during DLL initialization since you hold the loader lock.
So, good luck with that.
posted by jeffamaphone at 1:54 PM on February 9, 2010
The 100s of things that kill you are all the platform specific things. Like on Windows you can't call any functions that cause a DLL to be loaded during DLL initialization since you hold the loader lock.
So, good luck with that.
posted by jeffamaphone at 1:54 PM on February 9, 2010
This thread is closed to new comments.
posted by mkb at 11:13 AM on February 8, 2010 [1 favorite]