Threading

What MSDN is really trying to say here is that you can create almost as many threads as you want, limited by how much memory you have (for stack space), to a maximum of 2028 (''cuz windows is just plain odd). Threads are great, sometimes, because they let you seperate logical parts of your app, for example, you could use one thread to do graphics/physics, another for networking, another for sound, etc.

But, creating thousands of threads is stupid -- you''ll use up a lot of time just switching between threads -- and it''ll kill your app''s performance. Switching threads isn''t really a performance hit unless you do it too often -- say, if you''ve got 1200 threads. Threads are perfectly efficient if you are running one thread per processor (no thread switching needed), but most of us people only have one processor in our PCs, so that isn''t helpful. Most users are not blessed with a multi-processor PC. Also, the OS usually runs several threads on its own (there''s a lot of stuff going on behind the scenes).

Queues of request refers to making up your own threading system -- you have a bunch of queues, each of which can hold some number of requests (things that need to be done, or jobs). For example, you might have one queue for sounds, one for networking, one for graphics/physics -- you get the idea. The program would process everything in each queue before moving on the the next one.

A side note: Unreal Tournament does something like this for processing a bot''s AI. Each bot has its own script, and the game runs through a bit of each script every frame, in its own stack. Each bot is completely unaware that other bots are running their own scripts. The game acts like the OS here, cutting off each script after so many instructions. If there are too many bots in a game (like 500 or so) the game will choke and some bots won''t get to run their scripts very often. Then the bots get really dumb.

The bottom line is that a "queue of requests" is just another way of handling a lot of different things at once -- in fact, it''s only really useful if your app would have many, many threads, which isn''t often the case. (Side Note: It is in UT, because you want to have every bot run its own "logical thread")

One last thing: Threads are ALWAYS OS-dependant -- they won''t port directly, and you''ll have to rewrite a bunch of nasty code to get it to work. If you don''t care about putting your (I assume) Win32 app on a Linux box, then don''t worry about it. Otherwise, put threads on you list of things to rewrite for the port.

Happy coding, happy coder.



I will not allow school to interfere with my education.
--Khaydarian

As I see it.
Create a pool of threads with one thread per processor.
Those treads are waiting idle (waiting on a condition variable).

When you have something to do, create a queue (a FIFO), each entry holding enough information for the threads to do it (e.g. a function to call and the accompanying data). Have each thread pop items off the queue and process them until the queue is empty.

If you have something new to do, do not append to the queue the threads are consuming (synchronisation issues, loss of performance...) but create a new one.

Once the queue is empty, either start working on the next one or go back to sleep.


Look for "Worker thread pool" on the net.

[Questions (STFW) | GDNet Start Here | GDNet Search | Forum FAQ | Google | Asking Smart Questions ]
[Docs (RTFM) | MSDN | SGI''s STL | OpenGL | File formats]
[C++ Must Haves (RTFS) | MinGW | Boost | Loki | FLTK | SDL ]

Stolen from Magmai Kai Holmlor, who held it from Oluseyi, who was inspired by Kylotan...