Threading why multiprocessing is having issues.
Well the problem is a combination of the game and OS. Threading began to have support under linux circa 1997 in the kernel. What really is important is to understand how threading works and its mechanisms. This unfortunately has not been shown to be done much with games because threading is extremely complex and requires OS support. Windows threading is really fake threading, evne Linux threading isn't all that it's cracked up to be. Essentially threading splits multiple tasks up that are asynchronise too each other. An example of threading is copying from one drive to another under win2K and browsing a new section of the drive. That is threading in action. One thread is handling the GUI actions while another thread is handling actions executed on the file system. The kernel is being reentered frequently for this to happen, from multiple points and processes. That is threading.
So to make games take advantage of more cores etc. there are 2 things that must happen. First the OS must be able to split a thread to another processors. Second the code running on that other processor must be able to run independantly enough from the main code to be of use. An example of a good program for this to work with is VirtualDub. There are two processes going on with it, a foreground task of viewing the encoding monitoring progress reading and writing data etc. and a background task of processing the actual data and spitting the results out to the foreground task. With proper use of threading the background task which is extremely intensive could be split between 3 cores on a Quad Core unit and the foreground task can run on one core (reading writing spliting merging the data streams etc.) It's speed would significantly exceed that of a single core because the tasks would better utilize the existing resources. (IE speed would be better than just 4x)
So for a game to take advantage of this it would have to split up several processes in the game between threads. A primary thread for handling UI input loading and story etc. A second thread for rendering data. A third thread for moving and AI.. etc. It's not far fetched but it does require restructuring. It's not easy to do. Emulation has to do this. A thread is oft split off for the core of the emulator and the main UI. The main UI turns on and off the core that is doing most of the emulation. Synchronization is handled via the primary thread.
Even though this sounds great the OS must support true threading and be able to distinguish which processor the thread should operate on. Not an easy task.
I have to do this for an emulator I'm working on.. it's stalled because I'm being lazy.
Cyb
