Home Original page

gh-114271: Make `_thread.lock` thread-safe in free-threaded builds by mpage · Pull Request #116433 · python/cpython

@mpage 

…in free-threaded builds

Previously, the `locked` field was set after releasing the lock. This reverses
the order so that the `locked` field is set while the lock is still held.

There is still one thread-safety issue where `locked` is checked prior to
releasing the lock, however, in practice that will only be an issue when
unlocking the lock is contended, which should be rare.

@bedevere-app bot mentioned this pull request

Mar 6, 2024

@mpage mpage marked this pull request as ready for review

March 6, 2024 20:27

colesbury

adorilson pushed a commit to adorilson/cpython that referenced this pull request

Mar 25, 2024 
…lds (python#116433)

Previously, the `locked` field was set after releasing the lock. This reverses
the order so that the `locked` field is set while the lock is still held.

There is still one thread-safety issue where `locked` is checked prior to
releasing the lock, however, in practice that will only be an issue when
unlocking the lock is contended, which should be rare.

diegorusso pushed a commit to diegorusso/cpython that referenced this pull request

Apr 17, 2024 
…lds (python#116433)

Previously, the `locked` field was set after releasing the lock. This reverses
the order so that the `locked` field is set while the lock is still held.

There is still one thread-safety issue where `locked` is checked prior to
releasing the lock, however, in practice that will only be an issue when
unlocking the lock is contended, which should be rare.