You can play "what if" all you want if you don't know what else running, but this was always about lock free interprocess communication, which is not broken by a page fault or process suspension.
An atomic instruction by design will do everything it needs to when the instruction runs.
Saying the OS can ultimately control the execution of a process is a nonsense cop out to try to skew away from the original point.
all you ever wanted is anonymous memory
This is local to a process tree and does not work for interprocess communication.
If you map memory anonymously you aren't doing interprocess communication.
If you don't, you have a file path that the other program can use to map the same memory.
That's it, there is nothing wrong with this. I don't know why this is so upsetting. Mapping memory anonymously is local to the process tree and doesn't work for two different programs communicating.
It's also a fact that if I'm using disk swap space on a Unix, the same performance and stability issues apply as for disk backed file mappings. In that sense, there really is no difference.
> It doesn't matter what the OS does or doesn't do in the background, atomically reading and writing to memory is unaffected.
That's not true. If this thing is file backed there is usually no guarantee that the page of virtual memory (i.e. a page of the file data) you're accessing is present in physical memory. You'll cause page faults and data transfers to/from disk. This can delay the execution of an atomic read or write potentially infinitely, or even cause a "crash" of some kind if the disk transfer fails.
You can avoid the page faulting part of this if you somehow pin the memory. Which is completely ridiculous given that all you ever wanted is anonymous memory. I've looked up a website that seems to explain this better (but I haven't checked it deeply). Maybe it helps: https://eric-lo.gitbook.io/memory-mapped-io/pin-the-page