Multi-Thread Vs. Single-Thread

It depends on your platform, what performance effect free-threading has. On Win32 (even with a single processor) free-threading can yield a performance increase .

You don''t want two threads (much less more than two) spinning continuously, that''s thread-thrashing and it''s bad. You''re guaranteed to get less work done that way. You don''t want a large number of threads looking for a value or a flag to change - that''s polling and it''s inefficient.

With a multi-threaded system you have synchronization objects, such as events, that are made for this purpose. You can start up the UI/Windows message-pump in one thread, and have it hang waiting for a message indefinitely - that thread doesn''t use any processing time until a message is sent to it. Then the system message-pump sets an event and the kernel wakes the thread up to process the message. The application will exhibit _significantly better responsiveness because messages are dealt with as soon as they are received. If the application receives *alot* of messages this can be slower than queuing them up and batch-processing them. So if you go the multi-threaded route, make sure you use free-threaded designs and components (single-threaded components serialize access through the message-pump, which increases the number of messages being processed by a fair amount)

In my engine, I have one separate thread for the game loop. When the engine is initialized, it runs through all the sub-systems and initializes them. It has a call-back method (an observer pattern) that lets me display status information on the console as it starts up - at the same time the UI is completely responsive. You can move it around, the progress bar fills-up, etc... And low-and-behold, the cancel button actually works.

It simplifies the design, because each thread can just do it''s thing and stop when it doesn''t have anything to do. It complicates the implementation because you have to worry about what happens if two threads try to do something at the same time, and protect data access with critical sections.

Any IO intensive system is a good candidate for free-threading as well. Since IO operations take so long, you can use the CPU to do other things while another threads handles the IO operation. Window provides kernel mode objects, called IO completion ports, for this purpose. Instead of loading the entire level and then processing it, you can process it while it loads.

Now, you can do all those things without free-threading, but the design is more complicated because any lengthy operation needs to be redesigned so that it works in small chunks. It needs to remember how much work it completed the last time it was called, and stop working after so much time has elapsed.

If you use DirectX it will make a number of threads to handle things certain things. I''ll bet money that DirectSound spawns at least one extra thread that is used to fill the primary sound buffer - it ought to be a high priority if not a real-time one.

So yes, it''s a good idea to use threads when appropriate. Just make sure you''re not doing more work than makes sense. It''d be silly to update geometry data in a separate thread from the renderer. If you update the geometry more than once per rendering, you did work you didn''t have to do.

thx for the post, it was very informative. Now I''ve got a few more things to look into and research.

-Zims