Southern Bread

Windows has a pretty simple multi-thread interface. It has all the basics you would expect to keep your threads playing nice. It might not be totally POSIX but hey it’s Windows, what do you expect. That being said, when it comes to multi-threaded programming in Windows the problem is not with the API but with the programmer. It’s one of the hardest things to debug in the world of programming. And that goes for any OS. Not just Windows. Keep the following in mind and you will be a lot saner in the end:

1. If you just want threads so you can separate your GUI from your workers, fire off a master worker and have it use WaitForSingleObject
   to run any child worker threads you might need. This cuts down on complexity by keeping the flow somewhat linear but still giving that
   nice separation.
2. If you absolutely must have concurrent copies of the same thread running, be very judicious in your use of Critical Sections and Mutexes. This is where you will run into deadlocks and race conditions. These are essential for successful multi-threading but they will also bite you in the rear in a heartbeat.
3. Don’t forget about your main thread. Remember, you always have at least one thread running and you can’t exclude it from the mix when it comes to global variables and atomic sections.
4. The hardest glitches to debug will always happen in production and not in testing. You want to bring the complexity of your program
   up very slowly so you can fix small problems instead of big ones.

PodWrangler is multi-threaded but the worker threads don’t run concurrently. There really is no need since it would saturate most people’s DSL connections to have more that 1 or 2 downloads going at the same time. Take stock of your program and see if concurrent threads are really absolutely necessary. Most of the time they aren’t.