title: Are Reads and Writes of an int in C++ Atomic on x86-64 multi-core machine
body: <p>I've read <a href="https://stackoverflow.com/questions/5002046/atomicity-in-c-myth-or-reality">this</a>, my question is quite similar yet somewhat different.</p>
  
  <p>Note, I know C++0x does not guarantee that but I'm asking particularly for a multi-core machine like x86-64.</p>
  
  <p>Let's say we have 2 threads (pinned to 2 physical cores) running the following code:</p>
  
  <pre><code>// I know people may delcare volatile useless, but here I do NOT care memory reordering nor synchronization/
  // I just want to suppress complier optimization of using register.
  volatile int n; 
  
  void thread1() {
      for (;;)
          n = 0xABCD1234;
          // NOTE, I know ++n is not atomic,
          // but I do NOT care here.
          // what I cares is whether n can be 0x00001234, i.e. in the middle of the update from core-1's cache lines to main memory,
          // will core-2 see an incomplete value(like the first 2 bytes lost)?
          ++n; 
      }
  }
  
  void thread2() {
      while (true) {
          printf('%d', n);
      }
  }
  </code></pre>
  
  <p>Is it possible for thread 2 to see <code><b>n</b></code> to be something like 0x00001234, i.e. in the middle of the update from core-1's cache lines to main memory, will core-2 see an incomplete value?</p>
  
  <p>I know a single 4-byte <code><b>int</b></code> definitely fits into a typically 128-byte-long cache line, and if that <code><b>int</b></code> does store inside one cache line then I believe no issues here... yet what if it acrosses the cache line boundary? i.e. will it be possbile that some <code><strong>char</strong></code> already sit inside that cache line which makes first part of the <code><b>n</b></code> in one cache line and the other part in the next line? If that is the case, then core-2 may have a chance seeing an incomplete value, right?</p>
  
  <p>Also, I think unless making every <code><strong>char</strong></code> or <code><strong>short</strong></code> or other <code><b>less-than-4-bytes</b></code> types padded to be 4-byte-long, one can never guarantee a single <code><b>int</b></code> does not pass the cache line boundary, isn't it?</p>
  
  <p>If so, would that suggest generally even setting a single <code><strong>int</strong></code> is not guaranteed to be atomic on a x86-64 multi-core machine?</p>
  
  <p>I got this question because as I researched on this topic, various people in various posts seem agreed on that as long as the machine architecture is proper(e.g. x86-64) setting an <code><b>int</b></code> should be atomic. But as I argued above that does not hold, right?</p>
  
  <h1>UPDATE</h1>
  
  <p>I'd like to give some background of my question. I'm dealing with a real-time system, which is sampling some signal and putting the result into one global int, this is of course done in one thread. And in yet another thread I read this value and process it.
  I do not care the ordering of set and get, all I need is just a complete (vs. a corrrupted integer value) value.</p>