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, which is going to hurt performance and productivity and ultimately be a waste of time.

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!

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!