Make Ref<> assignments atomic

[ellenhp]

@RandomShaper

Describe the project you are working on

Godot Engine.

Describe the problem or limitation you are having in your project

I'm trying to implement #2299 and I'm running into issues. Godot seems to have a hard rule of no allocations or mutexes on the audio thread, but I'd still like to be able to modify data structures read by the audio thread in non-trivial ways from other threads. To do that without mutexes, I tentatively arrived on using a lockless singly linked list. It would be very convenient to use Ref<> for this.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Ref<> assignment will use an atomic exchange operation to swap its internal reference with the new reference. The semantics of the swap operation ensure that the Reference object that gets its count decremented is always the one that was replaced by the assignment.

Not doing this is dangerous and can cause leaks or use-after-frees. To understand the following claims you'll need to flip back and forth between this and the code. https://github.com/godotengine/godot/blob/master/core/object/reference.h#L60

Ref<X> r = obj1;
r = obj2; // Thread 1
r = obj2; // Thread 2

If the two threads run code in lock-step, the reference count of obj2 will be double-incremented. That's not too bad, it just just causes a leak. What's really bad is that it also double-decrements the reference count of obj1. Meaning there could be another Ref<X> somewhere pointing to obj1, and anyone accessing it will experience a use-after-free.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

Hopefully it's fine to just link to the PR here. godotengine/godot#46302

If this enhancement will not be used often, can it be worked around with a few lines of script?

No, thread safety can not be simulated in a script :)

Is there a reason why this should be core and not an add-on in the asset library?

This one answers itself I think. :) Ref<> is in core.

[ellenhp]

This was worked around by the addition of a lock-free linked list class called SafeList<>