>The C library has a very stable interface, so I wonder whether it could be made a shared component distributed with the OS?

That would put you in the same place as a lot of the *nixes where you would be stuck with whatever C++ features come with your distro. We don't want to do that.

>For all external interfaces, it is intended that _Atomic(T) is used (also for C++ compatibility).

Right, that means the lock needs to be in the atomic.

>It is then hopefully acceptable if the new atomic_ref-like C feature (if we get it) would then have similar constraints as atomic_ref in C++.

Sure, it would need to be within the same CRT "domain". I only raised a concern with that design being "_Atomic *" because that already has another meaning and is a completely different ABI.

>There is no other way to setup some common shared state between different C runtimes? Memory map a file at a well known location?

I don't believe there is such a "well known location" to use that would work all the way back to Vista. And even if we did do that, it would open up big cans of worms to figure out the lifetime of such a thing. Plus, I don't think CreateFile is safe to do under the loader lock (when the CRT startup code needs to run)

Billy3
________________________________
From: Uecker, Martin <Martin.Uecker_at_[hidden]>
Sent: Tuesday, June 22, 2021 01:07 PM
To: liaison_at_[hidden] <liaison_at_[hidden]>; Billy O'Neal (VC LIBS) <bion_at_[hidden]>; parallel_at_[hidden] <parallel_at_[hidden]>; ben.craig_at_[hidden] <ben.craig_at_[hidden]>
Subject: Re: [wg14/wg21 liaison] [isocpp-parallel] atomics in C++


Thank you for the explanation!

Am Dienstag, den 22.06.2021, 16:11 +0000 schrieb Billy O'Neal (VC LIBS):
>
> 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.

The C library has a very stable interface, so I wonder whether it
could be made a shared component distributed with the OS?

> > 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.

For all external interfaces, it is intended that _Atomic(T)
is used (also for C++ compatibility).

It is then hopefully acceptable if the new atomic_ref-like
C feature (if we get it) would then have similar constraints
as atomic_ref in C++.

> > 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.

There is no other way to setup some common shared
state between different C runtimes? Memory map a file at
a well known location?


Martin