Threading Jemgine
I recently made a false step into threading Jemgine. What I did was make scripts execute in their own thread. My scripting system isn't what you expect, though. There isn't a scripting language. Instead there are nodes connected in the editor. It is a sort of visual scripting language. This actually proved to be a really simple thing to do. But I immediately saw problems.
The simple problem is modifying the physics information associated with an entity. A script might want to apply a force, for example. Now, what happens if the script does this in the middle of the physics module being updated? Well, I don't know. I never actually saw it happen. Or if I did, I didn't recognize it. If that's the case then maybe it isn't such a big deal; but still I don't like it. As I said this is the simple problem. The solution is to queue all physics changes. It makes sense for a script that affects physics to do it through the physics module, and in a threaded situation it definitely has to. The physics module queues up all these impulses and what nots and applies them in between updates. It's not the most elegant solution, but it works well and solves that problem.
The harder problem is not setting data, it's reading it. The physics module updates the position stored in the entity after the update. If a script happens to read the position (or any other property that the physics module is in charge of) right when the physics module is updating it the script could get a half-updated value. I'm not sure if, in C#, it could get a half-modified float, but I know it could get a half-modified vector. Solving this is not hard per-se. What it requires is for the thread updating the physics information to stall any other thread querying that info until it is done with the updating. It sounds simple, but these properties are just simple values. I'd need to attach some access control to them. The simplest way to do that is to require the script to query this data through the simulation (Or the physics module, since it already owns the access control in question) But, this information is redily available through the entity itself. I don't like any solution that requires discipline on the part of the programmer, but I can't think of a better solution.
The hardest problem is when objects are destroyed. Creating them is no problem at all. No script can be using an entity that's not even created yet. But, when an object is deleted, who knows how many scripts are right in the middle of changing it. This might not be a problem. The object instance will remain valid as long as the script is refering to it. That's not the problem. But, it's components might not. Other things might vanish unexpectably if that entity is destroyed. And I see no simple way to solve this.
There are bigger problems. How do I create an entity in one thread if the physics are being created in another? Adding a new physics body in the middle of a physics update would be fatal to the simulation. But I can't delay it. I need those bodies created so I can create the joints. So, I need to stall this creation until the physics thread is done updating. Threading looks less and less valuable.
A database based (excuse me) system doesn't have these same problems. It has other problems, but these that are plaquing me are simple. Unfortunately, a database system isn't going to work with Box2d anytime soon.
So what threading options are available to me? Well, I can go forward with this way which, despite all the problems, does represent a signifigant performance increase, so long as you have multiple cores (And the 360 has 5). I would have to be stalling scripts all the time, but I can mitigate some of that by having multiple script threads running. The main problem here seems to be that scripts and physics run in different threads. What if they ran in the same thread and everything else ran in another? There would still need to be some synchronization. And the script/physics thread would have to keep track of timing information to keep the physics running smooth.
