Friday, April 28, 2006

Multi-tasking a "yuck"

I've been feeling a bit crap past couple of days, so never got around to updating here. Oh well.

I've started looking at threading my application at work, and have been trying to come up with the best way of doing it. Theres lots of ways you can thread an application, the simplest being you simply decided to run a bit of code on the other thread and it sleeps when its no busy. This is fine, and for tools usually what you need sine the other threads tend to be worker threads. But in games, you want to try and load balance a bit more - kind-of like what windows does, but a bit better.
So, I've come up with a way of using a thread pool that allows me to spawn off many tasks in the game as I come to them, this means that processes may switch back and forth from CPU to CPU, but allows the system to load balance it.

So how does this work in practice. Well, if you have 2 CPU's, you'll have 2 main running threads the second is synced to the first and will only start once its told to - it could even be a thread in the thread pool itself. These 2 threads then start ticking through the list of processes in their own time, meaning that if one slows down on a complex bit of processing, then other can pick up the slack. If something comes along that will block the thread - file or networking, then these are passed off to the threadpool but the file or network manager, and the main 2 threads carry on as normal.

It should work fairly well, and should allow for almost transparent use of multiple CPU's on the system. In theory.... However, if your application spends 95% of the time on one thing, then your still stuffed no matter what you do; you should learn to code better!

I love doing multi-threaded stuff, its greatfun seeing all your processes getting dished out and seeing all the available CPU's doing something. I have an old (very old) 12 processor SGI at home, and watching all the processor activity bars on the front being used to the fullest is very cool.

No comments: