On Linux, applications are required to load the libatomic shared library to correctly implement the full standard (on some older platforms like ARM, this is true even for small values since the hardware didn’t have an exchange instruction). There are a lot of operations that atomic int can do that volatile can’t do or will do incorrectly (such as seq-cst ordering or exchange). Why is this impossible for Windows? That sounds like a compiler implementation flaw, not an OS level impossibility.
Because Windows lets a process link to a library that has already been initialized by another process, so the process cant share its mutex during initialization, becaus the initialization has allready happend.
volotile gives you some decired propperties when multi-threadding, it is observable and therfor order rependent, but it does not have release/aquire semantics and it is not required to syncronize changes to other processors, so you need to use atomic intrincics in conjunction with volatile types. Volatile alone is NOT enough to be thread safe.
How do you link that? I thought I knew the API pretty well, but that is a new one for me.
volatile is only ordered with other volatile calls and is otherwise UB when combined with non-atomics. Whereas an atomic is well-defined for ordering on other operations too. There are even some operations (eg seq-cst on a set of memory locations) which are known to be incorrectly executed in certain scenarios if modeled with volatile+fence, and require the use of atomics.
Volatile is "observable" and all observable behaviour is order dependent. (so for instance a volatile and printef can not be reorderd, because both are obeservable). Howqever this is ONLY in a single threaded context. This is why you need a atomic intrincic operation to operate on a volatile for it to be thread safe.
Even on hardware where loads and srtores are atomic (x86), you still need the atomic ops to manage ordering.
What is “observable”? Only atomic seq-cst is order preserving, and even then only if there is no data races, and only if the compiler thinks it could even be observed by another thread. Otherwise, the compiler (and CPU) can and will choose to reorder operations. A printf call could even be reordered if the compiler could observe that it does not contain a volatile access. The volatile qualifier forces the operation to occur even if the compiler thinks the result would not be observable. But unless you work a lot with signals or memory mapped device registers, how is volatile even relevant, especially when the atomic ops are required anyways?
