Make RID_Owner lock-free for fetching.

[reduz]

This PR makes RID_Owner lock free for fetching values, this should give a very significant peformance boost where used.

Some considerations:

• A maximum number of elements to alocate must be given (by default 200k).
• Merged the validators and the data into a single struct, to make it more cache access friendly.
• Uses a mutex for thread safety since nowadays spinlocks are discouraged.
• Access to the RID structure is still safe given they are independent from addition/removals.
• RID access was never really thread-safe in the sense that the contents of the data are not protected anyway. Each server needs to implement locking as it sees fit.

[RandomShaper]

If I understand correctly, the thread-safe version has pre-allocate because otherwise memrealloc() can change the base pointer of the data. I'm wondering if that could be solved by using a PagedAllocator (UPDATE: or PagedArray, maybe is what I mean). Maybe the downside is that element access needs a bit of extra arithmetic and, more prominently, indirection to reach the item on the right page. Can you confirm?

[RandomShaper]

Suggested change

	if (THREAD_SAFE && chunk_count == chunk_limit) {
	if (unlikely(THREAD_SAFE && chunk_count == chunk_limit)) {

[RandomShaper]

Aside, given there's no need for thread safety on the data itself (requires external sync anyway), I'm wondering if we could go fully lock-free, this way:

• If thread-safe, validator becomes an std::atomic<uint32_t>, with load-acquire and store-release used on it.
• If not thread-safe, it keeps being a raw uint32_t.

PS: For the records, there's an idea I don't want to forget and so I'm writing it here: in case we still want locking, the SpinLock may still be advantageous, as it's sync variable could be used even for non-locky operations; e.g., to acquire-load on them. To avoid some of the downsides of it, we'd want to polish #85167. But, again, this is not relevant at the current status of the discussion.

[reduz]

@RandomShaper I am wondering if making the validator an atomic really changes anything, my fear is that load-acquire still forces the other CPUs to finalize other memory writes.

[RandomShaper]

Acquire-release atomics would at least be superior to either Mutex or SpinLock. The problem is thus with the functions that are now lock-less in this PR even in the thread-safe version. If we are fine with readers potentially seeing old data, those reads could be relaxed, but they have to be atomic in any case (in most or all relevant architectures that will boil down to plain reads, but the code would be more future-proof that way).

[reduz]

@RandomShaper I think in theory it should be fine if they see old data in this case, the data will not be accessible anyway after the mutex ends the lock, and will be updated when removed after the mutex also ends the lock. In the meantime, nothing should bother the data access so I think it should be ok. The data itself is not thread safe anyway, even now, so its not related to the actual RID access per se.

[Calinou]

Tested locally (rebased on top of master 10e1114 + #86333), it works as expected on Linux + NVIDIA.

On https://github.com/godotengine/tps-demo, it loads a full second faster than on master with neither PR applied.

[Calinou]

Out of curiosity, shouldn't the default value for p_maximum_amount_of_elements be a multiple of 65536?

[reduz]

yeah thats a good point

[clayjohn]

For context, we need to merge this before merging #90400, but we are in no rush to merge #90400 for now, so no pressure

[akien-mga]

Superseded by #97465.