Why Threads Are A Bad Idea (for most purposes) [pdf]

My guess is that people get scared off because the failure mode is so daunting. It's easy to write a threaded app that works fine for simple tests, then fails miserably when used under load. When that happens, it's nearly impossible to isolate a good test case for debugging. That's enough to scare off most people.

Another reason threads haven't become more popular is because operating system support is generally poor. It's rare for API documentation to say anything at all about multi-threading. There are common-sense rules for adding threads to Mac programs, but I discovered them more or less by trial an error, rather than anything I read in Apple's documentation.

BeOS not only had good support for threads, their use was in fact required in all GUI programs. Every single window runs in its own thread. That forces you to get good at multi-threading in a hurry.

The biggest mistake people make is creating too many locks. The most common failure mode is where thread A is holding lock 1 and is trying to acquire lock 2, while thread B is holding lock 2 and trying to acquire lock 1. A former boss (who worked at Be, as a matter of fact) suggested you can solve this one by always acquiring the locks in the same order everywhere. I say a better method is to never hold more than one lock at a time.

The best way to do that is share pretty much nothing between threads. Write each thread as if it were a separate program, as much as possible. Have the thread get new work out of a queue, and place finished work into a different queue. That way, you're guaranteed to never hold more than one lock at a time.

Successful multi-threaded programming requires a lot more discipline than normal. Failure to follow this rule means you'll be getting those impossible-to-debug lockups.

He suggests events as a simpler alternative. I would add: Unless you use a language with convenient concurrency semantics like Clojure.

I would recommend that anyone using threads run their program through the Helgrind tool from the Valgrind folk. It does a nice job of noticing if you missed a lock on a shared variable by instrumenting and analyzing your program at run time. (It caught me on one in my most recent program. I knew I hadn't started any threads when I made the access, still I should have had a lock there in case I later changed the initialization order.)

Each thread gets its own Tcl interpreter, and you pass messages back and forth between them. It's a much better approach than the "one big lock". I believe Perl takes a similar approach to Tcl.

1. Tell the O/S to decide which order all your tasks execute (Wow great I don't need to worry about all that).

2. Oops, now we don't know what order tasks will execute, so we have to program a whole heap of synchronization code.

OR

Do it yourself:

1. Program everything, so you know which order things occur, and don't need to worry about synchronization.

http://catb.org/~esr/writings/taoup/html/ch07s03.html

The conclusion is still accurate enough though, IMHO.

Locking order is important to prevent the classic deadlock, but there is nothing inherently 'too hard' for programmers in using threads.