AThousandShips
commented
2 weeks ago Please fill out the proposal with more details, especially alternative solutions and areas where it would be used
Things like:
- "Why is the existing synchronization primitives insufficient"
- "What in the use of Godot would these be used for"
- "What in the engine would use these"
Etc.
Describe the project you are working on
GDExtension running Luau inside Godot.
Describe the problem or limitation you are having in your project
Having to protect Luau states from multiple threads not knowing if they've been locked twice or not.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
Implement a RWLock class that internally uses a recursive RW lock.
The existing synchronization primitives do not provide a way to lock recursively which is a real bummer. Lets say we have an object that we have set up RWLock on. If we call a non-const qualified function, it will acquire the write recursive lock, and if its const, it will acquire the read lock. Lets say that while it locked it once, it would want to lock it again because it called another function. This would be one of the valid use cases for a recursive RWLock. Another use case would be inside GDExtension for libraries that work with multi-threading, with similar objectives as the first use case except this time it's no longer a Godot managed object.
GDScript may also use these, if they want to manage their own objects with multi-threading this would prove extremely important.
Not having a C++ implementation of this will result in massive losses of performance where GDScript requires a recursive lock implementation for certain things to work. A recursive RWLock is and always will be better than a recursive mutual exclusion if there are many things reading from the object.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
Similar methods to the non recursive RWLock, except it will be internally fully recursive.
If this enhancement will not be used often, can it be worked around with a few lines of script?
No as it requires a whole implementation.
Is there a reason why this should be core and not an add-on in the asset library?
This would allow users to use it in GDScript natively too to protect their objects from multiple threads by how Mutex (which uses a recursive mutex) already exists.