Use SRWLOCK in atomic_load operation on shared_ptr

[AlexGuteniev]

Fix #370

[StephanTLavavej]

Looks good to me. According to my understanding, there are no ABI concerns here - these functions were implemented in a single separately compiled TU, which is provided by either the static lib or the DLL, so there are no concerns about before-and-after mixing. The APIs being called are Vista+ (which we can now assume) and are Desktop/UWP ok.

[StephanTLavavej]

Thanks for improving performance here and fixing the priority inversion bug! 🚀

[sonyps5201314]

This PR makes CRT no longer compatible with XP, but 14.27 and earlier versions are fine

[miscco]

This PR makes CRT no longer compatible with XP, but 14.27 and earlier versions are fine

As far as I understand the whole support for XP was ripped out recently so you should not expect recent versions of the STL to work on XP

[sonyps5201314]

Why not remove XP running support when a new VS major release is released, instead choosing a minor version of VS2019 that is also undeclared and confusing to users?

[sonyps5201314]

This PR makes CRT no longer compatible with XP, but 14.27 and earlier versions are fine

As far as I understand the whole support for XP was ripped out recently so you should not expect recent versions of the STL to work on XP

The VS2019 16.8.0 VC14.28.29333 released yesterday did not quote the STL code from September 26 and later, so it should be able to maintain compatibility with the XP system.

[BillyONeal]

@sonyps5201314 We can no longer support XP, because XP doesn't support SHA2 code signing certificates, the SHA1 code signing certificates have expired, and the folks who own crypto refuse to mint new SHA1 code signing certificates. We're going to have to leave the last redist that supported XP available but you should not expect future STLs to work there.

Note that the VS2019 build tools officially dropped support for targeting XP following their deprecation in VS2017. (The IDE still supports targeting XP, but by using the VS2017 build tools options)

[sonyps5201314]

@BillyONeal
The name "Microsoft Visual C++ 2015-2019 Redistributable" will make users think that this installation package can be safely upgraded in place to replace the previously released "Microsoft Visual C++ 2015 Redistributable" and "Microsoft Visual C++ 2017 Redistributable", since 14.27 and earlier CRT versions is still compatible with XP,
Why not consider removing the CRT's support for XP in the next new major version of VS?

[BillyONeal]

@sonyps5201314 We are no longer capable of shipping software that can run on XP, because the signing certificates expired. The signing certificates expiring was not a thoughtfully considered decision, it was something happened because signing certificates have life spans. There's nothing the Visual C++ team can do about that without some form of time machine to go back to 2002 and give XP SHA2 certificate support (and to deploy unexpired root certificates to the world's XP machines).

since 14.27 and earlier CRT versions is still compatible with XP,

All support in the product to target XP was removed in 2019 RTM. (there is a v141_xp PlatformToolset but not a v142_xp one) Some parts of the product, including the Visual C++ team's redist DLLs, were updates to corresponding components from previous versions of the product which did support XP. As a result, as long as we could, we maintained backwards compatibility to XP there to simplify deployment for those older versions of the product.

[sonyps5201314]

@BillyONeal
Well, in fact, whether the file contains a digital signature is not very important. The early versions of CRT provided by Microsoft, such as VS2003 and VS2005 CRT, do not have a digital signature, and users can judge whether the CRT file is unmodified by the HASH value such as MD5.
UCRT, ATL and MFC are currently XP compatible，even the MFC program written by VS2019 can be easily compatible with XP by adding the /D "_ATL_XP_TARGETING" compilation parameter and the /SUBSYSTEM:WINDOWS",5.01" link parameter.
So I think there is no need to cancel the support for XP now. If users are worried about efficiency, they can use the onecore version of CRT to publish their own programs.
Thanks for your attention.

[BillyONeal]

Well, in fact, whether the file contains a digital signature is not very important.

I don't believe we can legally ship unsigned code. But this is getting close to legal advice so I'm not going into specifics.

The early versions of CRT provided by Microsoft, such as VS2003 and VS2005 CRT, do not have a digital signature

That's not true. They are catalog signed, but they are still signed.

UCRT, ATL and MFC are currently XP compatible，even the MFC program written by VS2019 can be easily compatible with XP

They are in "happens to work" territory, not "supported" territory.

[sonyps5201314]

OK, thank you for your patient explanation.