Multi-threaded handshake with a shared SSL_CTX became unstable (2–3x run-to-run) on Windows

Summary

Since master 24137d12a2e6 (first affected nightly; last good bf41baa2bf32, 2026-06-23) the perftools handshake benchmark — N threads handshaking against one shared SSL_CTX/OSSL_LIB_CTX — is erratic on Windows at ≥8 threads: consecutive nightly builds swing 2–3x and revert the next day (CV 28–33% at 16/32 threads; ~1% before). The same builds are stable on Linux, FreeBSD and macOS, which show only the expected ~+4% handshake cost of the ref-counting rework that landed in this range.

The context-isolated variants of the same benchmark, on the same Windows hosts and days, are unaffected — isolating the problem to the shared context:

windows-11 x86_64, 32 threads, daily runs since 06-25	CV
handshake (one shared SSL_CTX)	33.2%
handshake ssl_ctx pool	2.3%
handshake ossl_lib_ctx pool	1.3%
handshake ossl_lib_ctx per thread	1.1%

Suspected mechanism: the reworked refcount on the shared context is hammered by all threads; under Windows scheduling this degrades into intermittent lock-convoy-style stalls, where POSIX absorbs it as a flat ~4% cost.

Reproduction

perftools handshake with ≥8 threads on Windows 10/11, any master ≥ 2026-06-24; repeat runs vary up to 3x (worst at 16–32 threads, milder at 64). Control: handshake ossl_lib_ctx per thread on the same machine is stable.

Environment

• Affected: windows-10-x86, windows-10-x86_64, windows-11-x86_64 (all three of ours)
• Guests are CPU-pinned VMs, but virtualization is not the variable: POSIX guests on the same host are stable, bare-metal macOS shows the +4% step and no instability, and onset coincides exactly with the code change.