Sharing the memory of a loaded library is not a problem though. Every major operating system has done that for decades. That is just a consequence of copy-on-write pages though and doesn’t affect process isolation. Unless you meant something different than that?

There is also fork on posix systems, which is incompatible with using atomics in the child process for basically this reason though of accidentally partially sharing a loaded library between two processes. Most libc documentation will state that only async-safe calls are permitted after fork until exec for this reason.

the difference is that in windows if two applications load the same DLLs they don not just share code, they also share state and data. If a DLL has a global variable, it can be accessed by both applications.

This means that you can use DLLs as a mechanism to communicate between multiple applications.

Really? I can't believe that could possibly be true out of the box [1]. It would be a massive violation of process separation: buggy programs would be able to take down other processes, which is not something that really happens after WinME. I have 0 knowledge about Win32, do you have a pointer to some docs describing this behavior?

[1] of course even on unix you can mmap state on demand if you want to share between processes, but it is absolutely not the default.

Yeah, now that quelsolaar clarified, I am fairly certain that claim is not true, for exactly the reasons you describe. Of course, there is also the practical example of the mingw compiler, which does implement C11 for Windows, as a counter-example to their claim that it cannot be done.

So, there is probably a kernel of truth, as far as I know the DLL model in Windows is equivalent of RTLD_LOCAL, so global variables are actually instantiated per DLL (but of course not shared cross process), which for example makes allocation behave differently. So a spinlock pool between the main program and a DLL wouldn't be shared, making cross-DLL emulated atomics problematic. But I guess there are ways around that or simply the expectation is not to share non-address-free atomics across DLL boundaries.

In my experience, being similar to RTLD_LOCAL avoids a whole slew of sharing/unique accidents compared to the pile of hacks that is ELF. It is sometimes both the hardest and easiest platform to work with since it is the conceptually most consistent but also therefore the most primitive linker. But that is just not an issue, as the compiler must work anyways to ensure atomics work correctly per the platform ABI.

Indeed the problem is otherwise not restricted just to memory sharing: even the particular CPU instructions chosen can mean one compiler is incompatible with the output of a different compiler when it comes to atomics even when locks are not involved (the specifics of which barriers are used and where often mean there are multiple valid, but mutually incompatible ways, to emit atomic instructions)