Tim Stall wrote an interesting post about test harness code that exposes your possible multithreading bugs, and the performance costs of preventing those bugs with the C# lock keyword. And he linked to quite an old article by Mike Stall (don't ask me if there's a connection between the two, I've never met either of them) that I really liked. It buckets threading bugs according to how difficult they are to reproduce, understand, and fix. My favourite entry in the list is the last one:

10) Stuff that's provably unsolvable, but for which customers demand a solution anyways.

Been there, done that, alas no Tshirt.

Kate