There are differences between atomicity and thread synchronization. An atomic write means that the variable is always in a correct state. For example, a non-atomic write could write half of the integer in one instruction and the other half in other instruction, so a thread could see that intermediate, incoherent state (actually, a write of a integer is always atomic in 32/64 bits, but this is just an example).

But that the write is atomic does not mean that it is synchronized with other cores. For example, thread A in core 1 could write the value of x, but later thread B in core 2 could read an outdated from its L1 cache. You should use memory barriers that force cache refreshing, so all the threads always see the same version of the variable and do not rely on possibly outdated cachés.

About the unlocked stdio, I don't think there would be a clear advantage. For best performance, I/O is done in blocks as big as possible, so locking mechanisms should not matter that much (you spend much more time in the actual I/O than in the locking). It should only affect significantly when doing lots of I/O calls, but even in that case, removing the locks would not improve performance as much as grouping and batching those calls.

FTA: "In this post I’m going to do a silly, but interesting, exercise that should never be done in any program that actually matters."