>Out of curiosity: Why is this so? In principe, this does not sound imossible...

Names in Windows are namespaced into the DLL they come from. It isn't vector::vector, it's foo.dll!vector::vector. This is why, for example, local statics for functions in headers get one local static per DLL: when the function gets compiled into the different DLLs they are not the same function in our model.

Moreover. the standard library on Windows is not an OS component; it is like any other library. We can be statically linked into as many DLLs as the user wants, and because no names are shared between DLLs they have no means of finding each other or similar. The average Windows process has at least 3 standard libraries inside it (the kernel one, the OS user one, the one the program uses). This is why you can use brand new C++2023 features on Windows Vista from 2006, because in the "ordinary deployment model" you bring your own CRT.

>And does this imply that other state in the standard library is then also not shared between different parts of a program?

It does. If you pass, for example, a std::vector between DLLs that use different CRTs you are in undefined behavior land. (Where, in particular, debug features will end up using different locks since they are globals (!!!))

The difference is that we consider std::atomic "like Core" and don't want to force customers using it to follow the usual "can't cross CRT boundaries" rules with it. Whereas atomic_ref only provides the usual guarantees: 2 DLLs that each statically link the CRT and use atomic_ref between them do not actually get atomic access for non-lockfree atomics.

>All the C-runtimes could maybe depend on yet another DLL to host the lock table (I think atomic-ref does this?), but then you need to communicate to customers that they can't deploy applications using this variety of atomics unless they distribute the extra DLLs, and put it in system locations.

We can't do that even if we wanted to because customers must be able to statically link. We take a dim view of applocal deployment sometimes but there are plenty of reasons customers can't use our redist installers sometimes, e.g. single binary xcopy deployment required scenarios.
________________________________
From: Ben Craig <ben.craig_at_[hidden]>
Sent: Tuesday, June 22, 2021 06:16 AM
To: liaison_at_[hidden] <liaison_at_[hidden]>; parallel_at_[hidden] <parallel_at_[hidden]>; Billy O'Neal (VC LIBS) <bion_at_[hidden]>
Cc: Uecker, Martin <Martin.Uecker_at_[hidden]>
Subject: RE: [wg14/wg21 liaison] [isocpp-parallel] atomics in C++

> Am Montag, den 21.06.2021, 19:49 +0000 schrieb Billy O'Neal (VC LIBS):
> > (2 different DLLs which link different CRTs have no means to
> > coordinate on where the lock table lives)
>
> Out of curiosity: Why is this so? In principe, this does not sound imossible...
>
> And does this imply that other state in the standard library is then also not
> shared between different parts of a program?

Windows uses a different distribution model than Linux and Mac. The C-runtime that most users use is not an OS component. In addition, users can bundle an independent copy of the C-runtime with their application, through either static linking, or by bundling the DLLs in the same application directory.

All the C-runtimes could maybe depend on yet another DLL to host the lock table (I think atomic-ref does this?), but then you need to communicate to customers that they can't deploy applications using this variety of atomics unless they distribute the extra DLLs, and put it in system locations. Or you let the current distribution mechanism stand, and atomic refs that cross C-runtime "islands" aren't synchronized with each other, because each is using a different lock table.

And yes, this same argument applies to other global state in the standard library, though the solution space for each can be a little different.