Threads and Scheduling

If your application uses a bunch of threads, odds are, you're doing something wrong. The academic concept of threading is complicated, and it becomes only moreso in practice, when various chips behave differently and competing operating systems act like polar opposites. Lately, uber-Microserf Raymond Chen has been writing about all the ways naive thread-handling can mess you up. Listen to the man. He's one of the few people who implicitly understands threading on both an academic and practical level.

As a nice sort of counterpoint, Jeffrey Richter has been writing an MSDN Magazine article called Concurrent Affairs, which he promises will build a method to create performance-friendly, scalable threading synchronization.

As I read Chen's posts, I kept wondering when he was going to stop saying "...and the only way to avoid this is to use a real synchronization method" and actually show us a real synchronization method. I won't lie to you: threading is still a dark art to me. If my application is using a thread or two, then I know I've done something wrong. One process, one processor, that's my Arcadia. Maybe, if I really end up in the soup, I'll fork something.

But for those of you who are braver than I, threading is an everyday thing. And Chen and Richter are at least telling us what we should and should not do.