Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I'm rewriting a game engine I wrote in an attempt to parallelize as much as possible. I'm considering making properties which may be accessed from multiple threads all use accessors which use boost scoped_locks to avoid race conditions.

So then this way, say I have a character with base class CharacterBase. The X/Y/Z coords of the character are controlled through accessors with scoped locks. The main loop has 3 threads running, one to process physics, one to process rendering and one to process user input etc.

This will result in scoped_locks basically being everywhere and explicitly required by design when users are extending the engine. I am planning on making this open source so I'm wondering if there are any significant flaws or draw-backs in this design either from a technical perspective or end-user perspective (for those extending the engine). Thanks!

share|improve this question
2  
Boreal's answer was right. Try these links for more research info. gamedev.stackexchange.com/questions/2116/… –  Sean Middleditch Mar 21 '13 at 22:45
add comment

1 Answer 1

up vote 14 down vote accepted

You propose running each separate "system" in parallel. The problem with this is that you will have to lock every single piece of shared state. CLARITY EDIT: When you have two parallel operations using all of the same data, lock contention and synchronization is going to slow things down so that you're not gaining many benefits from the parallelization.

The key to multithreading a game engine is to realize that many systems perform SIMD-like operations, where a single operation is performed over a large number of game objects. One example is adding each object's acceleration to its velocity, and then adding its velocity to its position. When something like this is happening, you can spread the workload over multiple threads. You'll see huge performance increases when parallelizing CPU-intensive operations like pathfinding or collision checking.

This is better because it doesn't require locking the game state and does not introduce any problems relating to synchronization or racing. In fact, your main loop does not really need to change at all!

share|improve this answer
3  
+1 So to sum up, not very wise. This will surely avoid race conditions, but this is a road to bad performance and worse, dead locks. Ideal multithreading is lock-free. –  Laurent Couvidou Mar 21 '13 at 21:49
1  
Ideally, yes. Sharing a few variables here and there is fine, but if you need to lock down everything you're operating on, nothing is going to be able to run in parallel anyways. –  Boreal Mar 21 '13 at 21:52
    
Marked as correct although I've found some resources that suggest that the answer is subjective. preshing.com/20111118/locks-arent-slow-lock-contention-is. Anyway I'm not trying to be argumentative I agree with your answer now in that it is not the most ideal approach. Thanks for posting! –  Digital Architect Mar 23 '13 at 6:13
1  
Maybe I wasn't clear enough. When you have two parallel operations using all of the same data, lock contention and synchronization is going to slow things down so that you're not gaining many benefits from the parallelization. Very interesting article, though. –  Boreal Mar 23 '13 at 14:30
    
No I understood I was just saying that from the benchmarks in the referenced article even a relatively high amount of locking (320k per sec) showed there was still a performance gain of 1.5x over the single threaded version. It depends on how long locks are held etc. But in general and the way I asked my original question I agree with your answer that generally the performance is impacted negatively. –  Digital Architect Mar 23 '13 at 22:29
show 1 more comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.