7
\$\begingroup\$

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!

Improve this question
\$\endgroup\$
15
\$\begingroup\$

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!

Improve this answer
\$\endgroup\$
  • 4
    \$\begingroup\$ +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. \$\endgroup\$ – Laurent Couvidou Mar 21 '13 at 21:49
  • 1
    \$\begingroup\$ 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. \$\endgroup\$ – jmegaffin Mar 21 '13 at 21:52
  • \$\begingroup\$ 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! \$\endgroup\$ – user6484 Mar 23 '13 at 6:13
  • 1
    \$\begingroup\$ 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. \$\endgroup\$ – jmegaffin Mar 23 '13 at 14:30
  • \$\begingroup\$ 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. \$\endgroup\$ – user6484 Mar 23 '13 at 22:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy