So I have been doing research into multithreading for no reason other than curiosity and I have noticed something which I'd like to bring up.
The best way to multithread any software, apparently, is data-decomposition. As in instead of putting subsystems on different threads, you break up the processing of one subsystem into multiple jobs to do concurrently, scaling to n number of threads.
This is all fine and dandy, but say if you were to do this to the physics system, my logic would be to break it up so for n threads divide the number of objects by n and give each thread a group of objects to update. Then you would have a situation were conflicts would occur. Say object A collides with object B, but A and B are being updated at the same time on separate threads. Problem.
Another example is for updating game logic on gameObjects. What if object A is dependant on the health of object B. But again, they are being updated on different threads.
Now I know the simple answer is, minimize interaction and communication between objects, however this is not always going to be good enough, especially in physics, since object interaction is critical to the function of the system.
I have not worked on a game were objects never have to talk to each other, so how do you get around this problem when designing a multithreaded game?