+- Cuberite Forum (https://forum.cuberite.org)
+-- Forum: Cuberite (https://forum.cuberite.org/forum-4.html)
+--- Forum: Development (https://forum.cuberite.org/forum-13.html)
+--- Thread: Thread ownership of a World (/thread-1154.html)
RE: Thread ownership of a World - FakeTruth - 06-10-2013
(06-10-2013, 03:31 AM)xoft Wrote: Which is almost always
Can you give me an example?
RE: Thread ownership of a World - xoft - 06-10-2013
Anywhere a SetBlock, GetBlock or FastSetBlock is called on a cWorld object.
The point is, anything that is in the tick thread already has direct access to the chunk data, so those methods in the cWorld class are de facto the interface you're trying to create.
RE: Thread ownership of a World - FakeTruth - 06-10-2013
I don't understand what you're saying.
I think most accesses to the chunkmap are already done from from the Tick thread? With my solution the special cases that try to access the chunkmap from a different thread use the RunOnTickThread() function and we can get rid of all the CriticalSections. This should increase performance (though perhaps small) because no CriticalSections are being used and it makes it clear that the chunkmap can only be accessed by the Tick thread.
RE: Thread ownership of a World - xoft - 06-10-2013
It wouldn't increase performance at all.
Currently, the tick thread locks the chunkmap's CS, performs whatever it needs to, releases the CS, and waits for the next tick; the other threads can interact with the chunkmap.
In your version, the tick thread performs whatever it needs, then it locks the commandqueue's CS, executes the commands, releases the CS and waits for the next tick.
There's nothing saved and nothing gained; but it gives additional complexity and additional burden on the tick thread.
RE: Thread ownership of a World - FakeTruth - 06-10-2013
Oh right, you changed all that. Now the entity tick function gets a chunk reference. Hmm..
RE: Thread ownership of a World - xoft - 06-10-2013
Yup, all the tick functions receive a chunk reference, so that they can both access it directly (without locking - the tick thread already holds the CS) and don't need to search for it in the chunkmap's layers.
RE: Thread ownership of a World - xoft - 07-06-2013
I'm currently having thoughts very similar to what you must have had when you wrote your initial post. The threading in the server has gone a bit out of hands, especially with all the deadlocks lately.
RE: Thread ownership of a World - tonibm19 - 07-06-2013
Would a single-threaded problem fix deadlocks?
RE: Thread ownership of a World - xoft - 07-06-2013
Going back to single-threaded is both impossible and impractical - you'd lose performance on multi-core machines, and there's already so much code written dependent on the multithreading that we'd have to rewrite half of the server from scratch.
But still, there are a bit too many threads with not really well defined boundaries between them. We could definitely improve on that.
RE: Thread ownership of a World - FakeTruth - 07-06-2013
Perhaps you can some way visualize how threads and data interact with each other and come up with a solution from that.
Personally I have not had any training for visualizing relations in code, do you perhaps know anything about this?