Jump to content
  • Advertisement
Sign in to follow this  
Mantear

C++ and Win32: Threading basics

This topic is 3487 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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!

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!