What happens in the non threading targets like dos?
There it doesn't matter since no two threads on two different CPUs or cores will ever contend to access the same memory spot, so every access is atomic by default. Even the OS (=DOS) part abides by that.
Actually it does matter it doesn't do what advertises and it would be far better to raise an exception than to silently drop atomicity. I was hopping to write some short of multi threading lib for dos as an exercise and this little detail would have land me in a lot of trouble. Any way now I know and it does not affect me for the time being, thank you.
And why does it make any difference if the OS is threading or not? I though that the interlocked family of functions where based on the cpu ability for atomic operations not the OS multithreading capabilities.
Usually they are abstracted by the OS in some way. Some other synchronization primitives might need to interact with the scheduler (to block instead of busy waiting).
This post gives an idea what might need to be added to the cpu primitives (e.g. 32-bit primitives in 32-bit apps on 64-bit systems), and of course also a guarantee that all fences are in place.
From a quick look on the various links in that page my gut reaction is too much smoke not enough fire, specifically and I quote from the second paragraph on link of the accepted answer
A simple read or write on a field of 32 bits or less is always atomic. Operations on 64-bit fields are guaranteed to be atomic only in a 64-bit runtime environment.
That statement along tells me that I need to test every single statement on that article before accepting any conclusions it makes so this will take some time.
As for the interlocked operations they supposed to be atomic and atomic operations are a bit too low level to be abstracted like that they are not normal synchronization primitives and can't be handled like one or if you like to handle them like normal primitives then the compiler should provide an other way to access the atomic instructions, can't comment on the "fences" idea until I see what those fences are.
Aaaaaaany way its a mute point thank you for your time and hopefully this kind of information will be included in the documentation at some point.