1 reply to this topic

[keelx]

I like the idea of multithreading, and the idea of being able to perform multiple processes at one time. I can see how this would speed up a game significantly. But I just can't seem to come up with actually how to implement it.
How many threads should there be?
What would each do?
What should be controlled by each thread or another thread?
Would the threads be used for temporary, simultaneous events or for the entire length of runtime?

These are the main questions I'm having, basically about organization and what to actually put. What I'm thinking is have two runtime-length threads, one that performs physics and one that performs rendering, and then create a new thread on demand for things like dynamic resource loading/unloading, effects that I want to run simultaneous to the main loop, etc.

But I have no experience with such things. I need advice from someone who knows how to generally structure a multithreaded game.

[Telastyn]

How many threads should there be?

At most, 1 active thread for each idle core on the target machine (ideally).

What would each do?

Whatever allows it the least interaction/blocking with the other threads, and least overhead of creating the thread in the first place.

Would the threads be used for temporary, simultaneous events or for the entire length of runtime?

Creating and destroying threads are non-trivial from a resource usage perspective. Threadpools are generally used for more short-term work. Even that has some overhead.


Multithreading is a large, subtle topic. How you want to lay things out makes sense and is fairly common. The devil is, as always, in the details.