Skip to content
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

gh-114271: Make thread._rlock thread-safe in free-threaded builds #115102

Merged
merged 1 commit into from
Feb 16, 2024

Conversation

mpage
Copy link
Contributor

@mpage mpage commented Feb 6, 2024

The ID of the owning thread (rlock_owner) may be accessed by multiple threads without holding the underlying lock; relaxed atomics are used in place of the previous loads/stores.

The number of times that the lock has been acquired (rlock_count) is only ever accessed by the thread that holds the lock; we do not need to use atomics to access it.

The embedded lock (rlock_lock) is already thread-safe.

The ID of the owning thread (`rlock_owner`)  may be accessed by
multiple threads without holding the underlying lock; relaxed
atomics are used in place of the previous loads/stores.

The number of times that the lock has been acquired (`rlock_count`)
is only ever accessed by the thread that holds the lock; we do not
need to use atomics to access it.

The embedded lock (`rlock_lock`) is already thread-safe.
@mpage
Copy link
Contributor Author

mpage commented Feb 6, 2024

@colesbury - Can you add the "skip news" label?

Copy link
Contributor

@colesbury colesbury left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! This LGTM

@colesbury colesbury merged commit f366e21 into python:main Feb 16, 2024
38 checks passed
woodruffw pushed a commit to woodruffw-forks/cpython that referenced this pull request Mar 4, 2024
…ilds (python#115102)

The ID of the owning thread (`rlock_owner`) may be accessed by
multiple threads without holding the underlying lock; relaxed
atomics are used in place of the previous loads/stores.

The number of times that the lock has been acquired (`rlock_count`)
is only ever accessed by the thread that holds the lock; we do not
need to use atomics to access it.
diegorusso pushed a commit to diegorusso/cpython that referenced this pull request Apr 17, 2024
…ilds (python#115102)

The ID of the owning thread (`rlock_owner`) may be accessed by
multiple threads without holding the underlying lock; relaxed
atomics are used in place of the previous loads/stores.

The number of times that the lock has been acquired (`rlock_count`)
is only ever accessed by the thread that holds the lock; we do not
need to use atomics to access it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants