Greetings! I'm using C++/Win32 to create a simulation of a relatively large and complex system in order to test out some component designs that may eventually make it into the actual system. The simulated system consists of multiple state machines, I/O "devices", user interfaces, and signal processing. This had lead to the creation of quite a few threads. Each state machine has a thread, each I/O device has a thread, each user interface has a thread, the signal processing stuff has multiple threads, etc. The center of the application is a simple dialog window that is used to log the current state/status of all of the components and to allow the user to drive the I/O devices and user interfaces. All of the other threads talk to the main window using PostMessage(). The dialog application creates all of the threaded objects, starts and stops their threads, and passes handles around (in a somewhat messy manner, but I'm OK with that for now) so the threaded objects can talk to each other. Everything works just fine. My threads start and stop with no problems, the program can exit without any of the threads complaining, and all of the threaded objects can safely talk (using mutexes and semaphores, etc). The simulation is working just fine. However... My question boils down to good multi-threaded practices. The running of my event-driven state machine threads are controlled by semaphores. The running of my other threads are while() loops that contain a Sleep(1). Everything seems to run smoothly, and when idle, the program takes virtual no CPU time (0 according to Task Manager). But is that all there is to it? It seems a bit too easy and I feel like I'm missing something that my bite me later. Are while() { ... Sleep() } loops really the right thing to do? How many threads are reasonable? I'm currently at 10, but it's quickly growing. Any tips or pointers about multi-threaded application development would be appreciated. I'd like to avoid any pitfalls before I actually get to them. Thanks!

Quote:Original post by Mantear
The dialog application creates all of the threaded objects, starts and stops their threads, and passes handles around (in a somewhat messy manner, but I'm OK with that for now) so the threaded objects can talk to each other.

It's generally bad practice to forcibly terminate other threads. How are you 'stopping' threads?

Quote:Everything works just fine. My threads start and stop with no problems, the program can exit without any of the threads complaining, and all of the threaded objects can safely talk (using mutexes and semaphores, etc).

Are you 100% this is 'safe'? Have you proven it to be free of deadlock, etc?

Quote:Are while() { ... Sleep() } loops really the right thing to do? How many threads are reasonable? I'm currently at 10, but it's quickly growing.

If they're doing nothing, you can have hundreds if you like. But if they're doing a lot, there's little point having more than the number of CPUs you have. In your case it seems like they're just there to simulate asynchronous components so it's not a big deal. Use as many as you need. But bear in mind that switching from one to another is not the world's swiftest operation, so you may lose performance there - but if your CPU usage currently stands at about 0%, it matters not.

Quote:Any tips or pointers about multi-threaded application development would be appreciated.

Avoid mutexes or semaphores wherever you are able to use higher level synchronisation primitives. Also, send copies of data rather than locking shared data.