Thread safety and boundaries (free-threading Python)

[neutrinoceros]

Following PEP 703, the GIL is expected to be removed in main line Python in a few years. Python 3.13 is the first version to support disabling it (as a build-time option, mainly for testing).

The success of this multi-year long procedure depends on the ecosystem being able to adapt, so I think now is a great time to start thinking about it.
https://py-free-threading.github.io/ is a great resource to get started.

What I take from it is that we should define and test what parts of the API are meant to be thread-safe or not.
Off the top of my head, I see two areas in unyt where this would need to be addressed:

• UnitRegistry's self mutating methods should probably use a lock to prevent concurrent registrations/deletions or updates (specifically, anything that mutates the lut or _unit_object_cache attributes should be considered for locking)
• I don't think in-place mutation method in unyt_array could be made thread-safe, but we should probably document that they aren't.
• anything else ?

About our dependencies:

• NumPy is currently paving the way for free-threding Python compat in the scientific ecosystem
• I have not seen anything about this in sympy's repo, but I'll link back here if/when it happens.

[matthewturk]

Is it at all a possibility that while conducting operations on an array that the unit values change? I'm not sure that's covered under your first point, but perhaps it is.

[neutrinoceros]

Lemme think... mutating arrays in-place is never thread-safe (as far as I understand, this is the approach taken by NumPy folks). I think updating a unit registry (e.g. UnitRegistry.update) could probably not be completely thread safe since as it could affect conversions on any shared unyt_array using that registry... so I think this is a natural limitation we should probably call out in docs !