<mutex>: change mutex to be an SRWLOCK

[Amaroker]

Description std::mutex is currently powered by ConcRT to support Windows XP. As a result the size of mutex is too big to fit in a cache line.

When XP support can be dropped, the size can be reduced to sizeof(void*) by changing mutex to be an SRWLOCK, which is the highest performance lock provided by Windows.

Semi-duplicate description

• From #654 <mutex>: Implement mutex and recursive_mutex on SRW Lock. Support recursion only on recursive_mutex
  • correctness (constexpr construction)
  • no undesired strengthening (recursion on non-recursive deliberately not behaving correctly)
  • performance (no dynamic API binding => no control flow guard overhead; no recursion support overhead)

Additional context See also: Developer Community DevCom-334696 and Microsoft-internal VSO-685103 / AB#685103.

vNext note: Resolving this issue will require breaking binary compatibility. We won't be able to accept pull requests for this issue until the vNext branch is available. See #169 for more information.

[AlexGuteniev]

I'm not sure if it should be precisely SRWLOCK.

WaitOnAddress is also optimal, it can inline fast path, have 1 byte size, and allows implementing timed mutex without adding CONDITION_VARIABLE to the picture.

Still there are drawbacks of WaitOnAddress too, specifically having a fallback on Windows 7, and lack of debugging facilities (such as Application Verifier hooks).

---

But I'm sure we deserve something better than we have right now :-)

[StephanTLavavej]

Thanks, I've linked the Microsoft-internal bug to this issue! (And @BillyONeal implemented it in our long-lost vNext branch in 2018, but we'll have to retrieve that work from cryo-storage.)

[Chronial]

Duplicate to #654?

[StephanTLavavej]

Thanks @Chronial - they do look like near-duplicates, although that issue also talks about recursive_mutex. @AlexGuteniev, would you like me to fuse these issues together?

[AlexGuteniev]

Yes, sure

[StephanTLavavej]

Well, it's always an SRWLOCK now, it's just unnecessarily big until vNext, so I suppose we should keep that label.