-
-
Notifications
You must be signed in to change notification settings - Fork 32.4k
gh-136870: fix data races in instrumentation of bytecode #136994
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
77f5b45
to
443fc76
Compare
I think this makes sense, but it'd be helpful if @DinoV and @mpage can also take a look at it. From our discussion, locking code objects for de-instrumentation after calling tools isn't sufficient because other threads may be in the middle of running those code objects. We need a stop the world pause there, given the current design. |
I think this makes sense, but to make sure I understand correctly, the issue here is that without this change other threads may be using the tools concurrently with their removal. Is that right? |
The issue is that while the tools are removed which involves modifying thread local bytecode in |
Ah, ok. We intended to use atomics to avoid data races on the bytecode; looks we missed some places that should use them. Stop-the-world certainly fixes them and is easier to reason about, but it does come with a performance cost. I think that tradeoff is probably acceptable for now and we can revisit later if need be. |
I think we should include a NEWS entry and request a backport to 3.14 |
Thanks @kumaraditya303 for the PR 🌮🎉.. I'm working now to backport this PR to: 3.14. |
…nGH-136994) De-instrumenting code objects modifies the thread local bytecode for all threads as such, holding the critical section on the code object is not sufficient and leads to data races. Now, the de-instrumentation is now performed under a stop the world pause as such no thread races with executing the thread local bytecode while it is being de-instrumented. (cherry picked from commit 9a6b60a) Co-authored-by: Kumar Aditya <kumaraditya@python.org>
GH-137082 is a backport of this pull request to the 3.14 branch. |
De-instrumenting code objects modifies the thread local bytecode for all threads as such, holding the critical section on the code object is not sufficient and leads to data races. In this PR, the de-instrumentation is now performed under a stop the world pause as such no thread races with executing the thread local bytecode while it is being de-instrumented.