On Thu, Nov 14, 2019, at 07:43, Antoine Pitrou wrote: > On Wed, 13 Nov 2019 14:52:32 +0100 > Victor Stinner <vstin...@python.org> wrote: > > > > #define _PyRuntimeState_GetThreadState(runtime) \ > > > > ((PyThreadState*)_Py_atomic_load_relaxed(&(runtime)->gilstate.tstate_current)) > > #define _PyThreadState_GET() _PyRuntimeState_GetThreadState(&_PyRuntime) > > > > _PyThreadState_GET() uses "_Py_atomic_load_relaxed". I'm not used to > > C99 atomic conventions. The "memory_order_relaxed" documentation says: > > > > "Relaxed operation: there are no synchronization or ordering > > constraints imposed on other reads or writes, only this operation's > > atomicity is guaranteed (see Relaxed ordering below)" > > > > Note: I'm not even sure why Python currently uses an atomic operation. > > Is it protected by a lock? If not, you need to use an atomic. > Since it's theoretically possible to read the current thread state > without the GIL held (though not very useful), then an atomic is > required.
It sounds like you are saying PyRuntimeState_GetThreadState has two duties, then: "get this thread's thread state" (from the GIL holder - how do other threads get their own thread state), and "get the GIL-holding thread's thread state (from non-GIL holder thread). The former shouldn't need atomic/overhead locking (unless the thread state can be written from other threads), even if the latter does. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/4BNRSO47Z54MRR3ZS32W6DXYRVZ7U53W/ Code of Conduct: http://python.org/psf/codeofconduct/
