Windows Mutex implementation should be reevaluated on modern Windows targets

[Kixiron]

Currently the windows Mutex implementation has this comment at the top talking about its locking approach (using SRWLock instead of CriticalSection) with the justification that SRWLock performs better on Windows 7 and Windows 8.
However, in the (seven) years since, Microsoft has ended their Windows 7 support in 2020, Windows 10 became the dominant windows version and Windows 11 was released in 2021.
In light of these massive shifts in the windows ecosystem, our mutex implementation's speed should probably be reevaluated on the more modern Windows 10 and 11 platforms

[ChrisDenton]

For background, there's some old history here. Firefox and Chrome switched to SRWLOCK circa 2017.

It would be good to have some modern benchmarks.

[ChrisDenton]

cc @m-ou-se for tips on benchmarking mutex implementations.

[thomcc]

SRWLOCK was still faster in win10 when I checked a while ago (using a modification of the parking_lot benchmarks (which themselves are a port of webkits mutex benchmarks). This was with InitializeCriticalSection rather than one of the initializers that configures a spin count, so that may impact things.

FWIW, CRITICALSECTION doesn't have a static initializer (AFAIK), and can't be moved (according to https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-initializecriticalsectionex), so we might have to use lazy initialization like on pthreads.

I think the comment is just a bit stale, but it doesn't hurt to re-evaluate.

---

That said, I would be interested in seeing how the futex-based locks perform compare to SRWLOCK, since windows does have futex operations and could plausibly use them.

[ChrisDenton]

Closing this as we've now switched to using futex-based locks due to an issue with the OS SRWLOCK.