This is related to [this question](https://stackoverflow.com/questions/5596129/glib-g-atomic-int-get-becomes-no-op).

rmmh's claim on that question was that on certain architectures, no special magic is needed to implement atomic get and set. Specifically, in this case that g\_atomic\_int\_get(&foo) from glib gets expanded simply to (\*(&foo)). I understand that this means that foo will not be in an internally consistent state. However am I also guaranteed that foo won't be cached by a given CPU or core?

Specifically, if one thread is setting foo, and another reading it (using the glib g\_atomic\_\* functions), can I assume that the reader will see the updates to the variable made by the writer. Or is it possible for the writer to simply update the value in a register? For reference my target platform is gcc (4.1.2) on a multi-core multi-CPU X86\_64 machine.