The Dangerous Allure of Threads

"I have a training technique I use when we get new people in and they're very gung-ho. They'll say, "Oh, you guys seem really scared of threads, but I did them in college, and they weren't a problem for me!" You know that if someone isn't scared of threads, they haven't done any production code with them."

- Bruce Rogers, "Programmers' Roundtable," Game Developer, August 2007, p. 8.

"A computer is a state machine. Threads are for people who can't program state machines."

- Alan Cox

Why are threads so alluring? At first blush, they seem like the perfect solution for just about everything. When I first grokked threads, I thought: unimaginable power at my fingertips! But Bruce Rogers is right: if a person doesn't treat threads with a great deal of respect--isn't outright scared of threads--then that person simply hasn't implemented any real code with them. They're like home-made bombs: fun to build, but then they blow your hand off and ruin your day.

When I was managing a bunch of software developers at a previous employer (the one with the Satisfactory Resolution), there was one engineer I'll name Olbrag. Olbrag was completely in love with threads; in fact, he was so enamored that when tasked with architecting software for an embedded system, he came up with a design that required at least nine threads. I say "at least" because the design was remarkably flexible: Olbrag would enthusiastically pencil in another thread as the need arose. All this for a piece of software which did nothing more than (quickly) suck data out of a buffer and toss it into a socket, plus provide status. Olbrag wasn't fresh out of school, either. But he'd never worked on a real-time system before, a system with interrupt deadlines. He just didn't know.

When I first saw Olbrag's plan for his thread orgy, I got scared. Since I was ultimately responsible for the project, I set about dropping increasingly unsubtle hints that he should change his design. Olbrag was unfazed and unmoved. In retrospect, I think Olbrag had turned to a threaded architecture in order to avoid designing a proper state machine. State machines admittedly entail their own challenges, but at least you can actually debug them.

In the end, I got a couple of other senior engineers to gang up on Olbrag (in a nice way) and say look--you can avoid a whole lotta pain for yourself by consolidating some of those threads. Olbrag agreed to rethink his design, and by the time we delivered the code, the implementation was thread-bare: a mere two threads. Even then, the system was a pain to debug. At one point, we recruited somebody with remarkably steady hands to solder infinitesimally fine wires to the board's surface mount LEDs. I attached oscilloscope probes to the wires, then sprinkled LED-flippy instructions throughout the code. And all this effort to debug a mere two threads.