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

I meant only C, not C++. The C library is much more stable
and rarely gets new features.

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

Yes, this is then up to the implementation.

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

My original was to split up the qualifier _Atomic T and the
specifier_Atomic(T), but it is probably better to deprecate
the qualifier _Atomic T and introduce something new.

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

The OS team does not want to help? Not being able
to create process-wide shared space in the C library
seems like a pretty fundamental limitation.

Martin


>
> Billy3
> ________________________________
> From: Uecker, Martin <Martin.Uecker_at_med.uni-goettingen.de>
> Sent: Tuesday, June 22, 2021 01:07 PM
> To: liaison_at_[hidden] <liaison_at_lists.isocpp.org>; Billy O'Neal (VC LIBS) <
> bion_at_microsoft.com>; parallel_at_lists.isocpp.org <parallel_at_lists.isocpp.org>; ben.craig_at_ni.com <
> 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
>
>
>
>
>