Atomic do impose an odering.
f() is sequenced before g(). If g() preforms an release on an atomic 'gatom', then it synchronizes with a future thread that does an aquire on 'gatom'. Then in that...
Type: Posts; User: King Mir
Atomic do impose an odering.
f() is sequenced before g(). If g() preforms an release on an atomic 'gatom', then it synchronizes with a future thread that does an aquire on 'gatom'. Then in that...
It has to either assume that any unresolvable function modifies an atomic, and therefore not reorder, or reorder when linking. Also, the CPU can reorder. Additionally, The C standard does not require...
I agree with all of what you said except this nitpick: That quote 's correct, as long as the order of IO and threading primatives is the same.
But you can and must reason about the order of access...
Atomics and mutexes do change things, because an implementation (compiler or CPU) is not expected to guarantee that ordering optimisations don't change observable effects when accessing memory...
For IO that's saying the same thing in a different way. For C11 concurrency though, trying to define the guarantees provided my atomics and mutexes as an "effect" seems awkward at best. I suppose...
Also, even in grumpy's code, the order of evaluation may not be fixed if f(), g(), and h() do not do IO, access atomics, mutexes, or volitile variables, or access the same memory location. Basically...