Thread ownership of a World

[FakeTruth]

Which is almost always

Can you give me an example?

[xoft]

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.

[FakeTruth]

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.

[xoft]

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.

[FakeTruth]

Oh right, you changed all that. Now the entity tick function gets a chunk reference. Hmm..

[xoft]

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.

[xoft]

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.

[tonibm19]

Would a single-threaded problem fix deadlocks?

[xoft]

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.

[FakeTruth]

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?