"Threads cause programs to fail in new and exciting ways"

That saying was written in a guide that's published here to help programmers understand various standards of internal development. I laughed at this since it's so true. Today I realized I had been a victim of this very statement. I'd been writing multi-threaded applications for a few years now. I figured I had understood most of the nuances and problems associated with multi-threaded programming.

Today I was trying to debug a weird problem in a multi-threaded program I had written in C#. While diagnosing the problem, I noticed another bizarre behavior. It turns out that I was a bit overzealous with some of the threadlocking that I was doing. This was one of the first multi-threaded programs that I had written in C#, so I was still trying to pick up the .NET way of using multi-threading. It looks like in an effort to fix a bug (or many) I thought was threading related, I went and put a bunch of locks on variables that didn't need to be locked. It ended up slowing the whole thing down to a crawl (not to mention causing various network functions it was performing to time-out because of it). Oops.

Now that it's fixed, it feels about 30-40 times faster. Gee, perhaps that's because my multi-threaded program was getting so mucked up that at 50 threads, it was running like it had only 2.

It just goes to show you, threads really do cause new and exciting failures, even for those who should know better.