Back to General and Gameplay Programming

Architecture for multithreading

Trapper Zoid · 2009-12-12T03:48:32

I'm working on a few quick game projects, and I'd like to use this opportunity to experiment with some new architecture approaches. With my projects being generally quite small, I've previously never had a need to look into multithreading, but with multiple cores being ubiquitous these days it feels like a large gap in my knowledge. I'd like to steer my development direction towards writing multiple-thread, multiple-core friendly code and I've read up on the basic nuts and bolts (starting threads, mutexes etc.); I'm just a bit lost as to the steps I should go in to plan the high-level architecture to be multithread friendly. My current single-threaded approach to a game system would be to create a kernel acting as the main game loop, where the main tasks that need to run every loop get registered and called every cycle. I'd have tasks for world update, rendering, input polling, updating the timers and so on, registered to the kernel and somewhat independent from each other, although they do tend to share some information through what are effectively global data structure (such as things like the latest time update delta). They also tend to share some code elements such as the logging system. From what I gather an easy way to multithread this would be to split the tasks into some large threads, for example: A main thread for gameplay elements A render thread Maybe a resource management thread for files, textures, memory etc. And technically maybe threads for some smaller subsystems like audio, which the libraries I use most likely handle invisibly to me This way there are only two large threads, the gameplay one and the render one, which can communicate through a shared data block of renderable elements, which the gameplay thread writes to and the renderer reads, which I can keep a close eye on to avoid thread issues. This seems pretty straightforward to do, but it doesn't sound very scalable to more advanced threading systems and it doesn't solve issues like a shared logging system I'm guessing my stumbling point is understanding the best ways threads in a game system can safely communicate with each other, and what that means for how to structure the tasks in a game system into an architecture that makes sense with those limitations. I'd be grateful if someone could explain at a high-level how they'd personally go about structuring a multithread friendly system and the interfaces they'd use between threads. Maybe with a bit of discussion that the nature of the problem will "click" with me. Thanks.

General and Gameplay Programming Programming Unity

Started by Trapper Zoid December 09, 2009 07:13 PM

10 comments, last by elFarto 14 years, 4 months ago

Hodgman

52,717

December 12, 2009 12:27 AM

Quote:Original post by elFarto
Quote:Original post by phantom
As a side note, I'm a fan of the design where you have everything update its logic at once, then run a 2nd 'sync' step.
I'm a fan of global state being transactional. Each entity's update process uses the latest global state and is not effected by state changing while it's running (ie. starting a transaction 'freezes' your view of the world). While this doesn't solve all the problem, and introduces live-locks, it seems to work quite well and it neatly side steps synchronisation issues (deadlocks).

Does this approach support deterministic simulations? Or would the random order of threaded updates cause the order of actions to be random as well?
With the 2-step approach all entities are working from the same 'snapshot' every update, so you can still enforce determinism.

It's not an essential feature, but is required by some games.

. 22 Racing Series .

elFarto

207

December 12, 2009 03:48 AM

Quote:Original post by Hodgman
Does this approach support deterministic simulations? Or would the random order of threaded updates cause the order of actions to be random as well?

No, it doesn't support deterministic simulations, since as you pointed out you can't control the order in which the update occur.

Regards
elFarto

Architecture for multithreading

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Architecture for multithreading

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines