06-10-2013, 12:18 AM
That's not true. The chunkmap *is* accessed from multiple threads - the tick thread, the generator thread, the storage thread and the socket threads. Therefore, it needs locking.
I'm failing to see what exactly is your point with this. It feels like quite a big change, yet I cannot see any advantage that it would bring, aside from being "academically more elegant". Also, why do you want an object to be owned by a thread? I think a much better approach is to have objects own other objects, with the owned objects possibly representing threads. That makes much more sense, since usually you have one main thread in an app, and then a lot of local worker threads, that operate locally on several objects.
One thing that I've noted about your proposed design is that it's prone to cache contention. You're effectively shuffling data between threads; those threads may run in parallel on different cores, so the data that they access must be synchronized across each core's caches. That slows operations quite considerably, if the code does that, it can run orders of magnitude slower. Since that is quite a delicate and intricate thing, I'd rather not mess with it and rather go around it.
That said, it's true that there are deficiencies in the current object model that we're using. I'm just too lazy to rewrite stuff. I think the cRoot should own the cServer object and cWorld objects; each cWorld should own its own tick thread etc. Also, the main app thread should call cRoot:Initialize() and the method should create threads and then return; the main app thread should be doing what now the InputThread does (so when we decide to wrap some kind of a GUI around it, it's easy to do so).
I'm failing to see what exactly is your point with this. It feels like quite a big change, yet I cannot see any advantage that it would bring, aside from being "academically more elegant". Also, why do you want an object to be owned by a thread? I think a much better approach is to have objects own other objects, with the owned objects possibly representing threads. That makes much more sense, since usually you have one main thread in an app, and then a lot of local worker threads, that operate locally on several objects.
One thing that I've noted about your proposed design is that it's prone to cache contention. You're effectively shuffling data between threads; those threads may run in parallel on different cores, so the data that they access must be synchronized across each core's caches. That slows operations quite considerably, if the code does that, it can run orders of magnitude slower. Since that is quite a delicate and intricate thing, I'd rather not mess with it and rather go around it.
That said, it's true that there are deficiencies in the current object model that we're using. I'm just too lazy to rewrite stuff. I think the cRoot should own the cServer object and cWorld objects; each cWorld should own its own tick thread etc. Also, the main app thread should call cRoot:Initialize() and the method should create threads and then return; the main app thread should be doing what now the InputThread does (so when we decide to wrap some kind of a GUI around it, it's easy to do so).