gh-128942: make arraymodule.c free-thread safe #128943
Conversation
|
Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool. If this change has little impact on Python users, wait for a maintainer to apply the |
|
Requesting a look from @ZeroIntensity. |
There was a problem hiding this comment.
Thanks for doing this! At a glance, don't use goto with critical sections--it's messier and can be error-prone (IIRC there's problems with it compiling on MSVC too). Instead, create a wrapper function like this:
static PyObject *
array_something(arrayobject *self, PyObject *arg)
{
PyObject *res;
Py_BEGIN_CRITICAL_SECTION(self);
res = array_something_lock_held(); // the actual implementation function
Py_END_CRITICAL_SECTION();
return res;
}For functions that are defined with the Argument Clinic, you can use @critical_section to do this even faster. (See what I did for the ssl module.)
|
Made requested changes, also made arrayiter safe. Also found a good old-fashioned non-free-threaded bug which probably goes back a long way - if try to Question remaining about need to lock bytes source object in |
Could you separate that out from this PR and submit a dedicated PR for this bug? We might want to backport it. |
|
Regarding the style nits: please make sure all new code (and in most cases, also changed code) follow PEP-7. |
|
Still would like to know if |
Misc/NEWS.d/next/Library/2025-01-17-13-53-32.gh-issue-128942.DxzaIg.rst
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
We're getting there! Now, we're overlocking things a bit. This isn't always the rule, but in general you only need to lock something if you want to avoid inconsistent state (making it a "critical section"!).
That, and keep in mind that things that have a _Py or Py prefix are generally thread safe themselves and will lock if they need to. You don't need to lock for every call to Python.
❯ ./python -m test test_array -R 3:3
Using random seed: 1919100667
0:00:00 load avg: 36.22 Run 1 test sequentially in a single process
0:00:00 load avg: 36.22 [1/1] test_array
beginning 6 repetitions. Showing number of leaks (. for 0 or less, X for 10 or more)
123:456
XX. ...
0:00:16 load avg: 28.56 [1/1] test_array passed
== Tests result: SUCCESS ==
1 test OK.
Total duration: 16.1 sec
Total tests: run=886 skipped=1
Total test files: run=1/1
Result: SUCCESSNo refleaks. |
Thx for the onboarding with this @ZeroIntensity |
|
The PR regressed free threading performance substantially on the scimark benchmarks from pyperformance, so I'm going to revert the PR for now. We'll need to figure out a way of making |
…)" The change regressed performance on scimark benchmarks from the pyperformance benchmark suite. This reverts commit 8ba0d7b.
Will play with it checking perf along the way to see if a lesser standard of thread-safe can work (ignore data integrity and just make sure nothing crashes). |
|
I looked at it briefly under Linux's
We can consider using a similar strategy as We can also consider moving |
List deals with objects with their own |
|
I guess it'll be a bit simpler than So if we adapt the list strategy it might look like:
|
Simplest worst case scenario thing depending on performance could be a spinlock to make access to In any case, got some crude numbers for impact of just I have all weekend to play with this so will try various things and what you mentioned. |
|
Continued in #130771. |
This PR is a work in progress but it currently fixes the crashes mentioned in the related issue so I am sending it up now to elicit feedback to make sure I am on the right path. So far the changes have been made functional but as minimal as possible to facilitate review. The critical sections are fairly broad so optimization may follow if functionality is confirmed. The changes are mostly additions of critical sections to publicly visible methods and slots gotten from the two structures listed below (as well as a few internal functions):
The following public methods/slots have been modified directly:
The following have not been modified but depend for safety on the functions they call:
The following look safe as is:
And the following non-public utility functions have been made safe:
Here are a few questions needing guidance:
Changed clinic sig of
array_array_frombytes()so I could lock the original source object during op (maybe its a writeable bytearray). Want to prevent modification of data during the operation but not sure this will even do this so not sure is necessary or even desired. Should I remove this and leave just thePyObject_GetBuffer()for protection? Also for this added a forward declaration ofarray_array_frombytes()forarray_array_fromfile_impl()instead of moving stuff around for minimal impact.In
array_newthere may or may not be an initializer object, if there is not then theargstuple is used as a stand-in for the critical section lock. Is there a better way to do this?Misc:
array_richcomparewas incrementing refcount ofPy_TrueandPy_False, removed that as they are immortal.The following were larger / slightly more complicated functions to check so should double check
array_array_frombytes,array_richcompare,array_ass_subscrandarray_new.More work is still needed, like the array iterator and more testing and verification.
arraymodule is not free-thread safe. #128942