I''m building a game engine, and I read a lot about multiple threads, and how they could increase the responsiveness and efficiency of a game (if they''re used properly, of course). Here''s how my engine looks so far: the main thread simply uses the GetMessage()/DispatchMessage() loop. In the beginning of WinMain, I create a second thread, which manages the game engine. That thread creates three more threads to handle video, sound, and input. And here''s my problem: how do I have my "game engine" thread (the second one) manage the three other threads? I have a queue with locks on it, for each of the three threads (video, sound, and input), where I can place tasks for them to process. Should I have the "game engine" thread dispatch tasks to control them? How specific should I make the tasks? I would like to "leave the door wide open" for making those three threads as interchangeable as possible (i.e., creating another thread function that uses OpenGL instead of DX for rendering). What level of abstraction can I use? I''m stuck here! [sigh] Or, I can basically eliminate the "game engine" thread, and just have the other three (video, sound, and input) process a giant struct with state information. What should I do? Has anyone had similar experience with this? Thanks in advance for your time! - null_pointer

If it were me, I would only use a separate thread for input, since that happens asynchronously. Other things like video and sound are much easier kept in the same thread. But if you insist on doing it this way (at least you will learn a lot about multithreading) then yes a global shared struct would probably be easiest. Just make sure you use semaphores to protect it from multiple threads accessing it at the same time.

You can still keep the graphics interface logically separated even if the video is not in a separate thread. In fact this is a good practice in general.

OK, thanks!

BTW, my video and sound interfaces are about as logically separated as they can possibly be. You simply new the video_subsystem object at the beginning of the program, and then delete it at the end. It''s derived from a thread class that I made...classes make everything easier. But making the state information logically separate and "generic" will take some work.

Like you said, though, three threads is probably overkill...but I did create this project to learn multithreading.

Thanks again!


- null_pointer