gh-140795: fetch thread state once on fast path for critical sections

[kumaraditya303]

Currently on the fastpath for critical section where the objects are not locked, the thread state is fetched twice once while acquiring it and once while releasing it. This PR optimizes it to fetch it once and store it (in a temp variable on stack) so that on the fastpath thread state is fetched once.
This should help performance in shared modules such as ssl where thread state access is slower because of extra function call to _PyThreadState_GetCurrent.

• Issue: performance regression in ssl module under free-threading #140795

[colesbury]

How much of a difference does this make to asyncio_tcp_ssl?

[kumaraditya303]

How much of a difference does this make to asyncio_tcp_ssl?

It is ~5% faster on macOS with this change.

[encukou]

I don't understand why this is only done for Py_BUILD_CORE code. Is there a reason to exclude non-stdlib users of critical sections?

Putting the thread state in a temp stack variable for all users seems to work well: https://github.com/python/cpython/pull/146066/files

[colesbury]

I wouldn't necessarily expect it to help non-stdlib users. There are basically three cases:

1. Python interpreter core (main executable)
2. Python extensions that don't build with Py_BUILD_CORE
3. Python stdlib extensions that use Py_BUILD_CORE (e.g., _ssl)

In the main executable, everything gets inlined and the access to _Py_tss_tstate is typically very fast. Additionally, in some cases, the compiler can remove redundant loads of _Py_tss_tstate.

In non-stdlib extensions, the calls are not inlined. The access to _Py_tss_tstate is again typically in the main executable, so it's very fast (often a single memory load).

In extensions like _ssl, the critical section calls are inlined, but now the access to _Py_tss_tstate is happening in a shared library. The access to TLS from a shared library usually requires a function call, so it's slower. That's the unique case that this PR was meant to address.