From 880afcfcc505f106dbc5d4873c7099eb1cd5b940 Mon Sep 17 00:00:00 2001 From: Matt Page Date: Wed, 6 Mar 2024 11:26:36 -0800 Subject: [PATCH] gh-114271: Make the common usage of `_thread.lock` thread-safe 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. --- Modules/_threadmodule.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Modules/_threadmodule.c b/Modules/_threadmodule.c index 3a8f77d6dfbbc6..7587ac00eef60c 100644 --- a/Modules/_threadmodule.c +++ b/Modules/_threadmodule.c @@ -390,8 +390,8 @@ lock_PyThread_release_lock(lockobject *self, PyObject *Py_UNUSED(ignored)) return NULL; } - PyThread_release_lock(self->lock_lock); self->locked = 0; + PyThread_release_lock(self->lock_lock); Py_RETURN_NONE; } @@ -1665,8 +1665,8 @@ release_sentinel(void *weakref_raw) lockobject *lock = (lockobject *)_PyWeakref_GET_REF(weakref); if (lock != NULL) { if (lock->locked) { - PyThread_release_lock(lock->lock_lock); lock->locked = 0; + PyThread_release_lock(lock->lock_lock); } Py_DECREF(lock); }