Choice of Slim RW Lock over Critical Section for std::mutex?

[danieljennings]

Hi friends, I'm just curious about the choice of Slim RW Locks over Critical Sections for std::mutex, given the traditional advice from the Microsoft documentation is that SRW will only out-perform CS when read operations exceed write operations*. Obviously std::mutex only ever takes exclusive access to the underlying lock object, so there's no read operation to consider. Furthermore, SRW locks derive some of their value from their smaller memory footprint, but that doesn't appear to be true with the STL mutex code, which still has a CS-sized footprint (which I presume is to avoid breaking ABI). But nevertheless, the STL mutex code has been migrated over the years away from CS toward SRW. The only other benefit I'm aware of is the ~free construction/destruction of SRW objects compared to the library call needed for CS.

* I do recognize that there are random benchmarks online that show SRW outpacing CS even outside of read/write contention, so maybe the documentation is just wrong nowadays.

Thanks

[sylveon]

FWIW other MS products also prefer SRW locks for mutex purposes. WIL and cppwinrt are two examples that come to mind. This advice from MS docs may no longer be true.

[CaseyCarter]

IIRC, Windows folks told us to prefer SRW when the threading primitives were last overhauled in 2016 (which changes we haven't been able to ship due to the joys of ABI stability). I don't have hard numbers to hand, but I'd be surprised if the implementer, who was our perf champ at the time, didn't do some performance investigation as well.

I will note that SRW's ease of construction also makes it possible for us to make std::mutex's constructor constexpr as required by the Standard since C++11.

[danieljennings]

Thanks Casey!